chore(Pipfiles): update odh-elyra to version 4.2.3 across all Pipfiles #1591
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Bumps [jupyterlab-git](https://github.com/jupyterlab/jupyterlab-git) from 0.50.2 to 0.51.1. - [Release notes](https://github.com/jupyterlab/jupyterlab-git/releases) - [Changelog](https://github.com/jupyterlab/jupyterlab-git/blob/main/CHANGELOG.md) - [Commits](jupyterlab/jupyterlab-git@v0.50.2...v0.51.1) --- updated-dependencies: - dependency-name: jupyterlab-git dependency-version: 0.51.1 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <[email protected]>
jiridanek
added
the
tide/merge-method-squash
WalkthroughThis change updates the Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. ✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
jiridanek
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (13)
jupyter/datascience/ubi9-python-3.11/Pipfile(1 hunks)jupyter/datascience/ubi9-python-3.12/Pipfile(1 hunks)jupyter/minimal/ubi9-python-3.11/Pipfile(1 hunks)jupyter/minimal/ubi9-python-3.12/Pipfile(1 hunks)jupyter/pytorch/ubi9-python-3.11/Pipfile(1 hunks)jupyter/pytorch/ubi9-python-3.12/Pipfile(1 hunks)jupyter/rocm/pytorch/ubi9-python-3.11/Pipfile(1 hunks)jupyter/rocm/pytorch/ubi9-python-3.12/Pipfile(1 hunks)jupyter/rocm/tensorflow/ubi9-python-3.11/Pipfile(1 hunks)jupyter/tensorflow/ubi9-python-3.11/Pipfile(1 hunks)jupyter/tensorflow/ubi9-python-3.12/Pipfile(1 hunks)jupyter/trustyai/ubi9-python-3.11/Pipfile(1 hunks)jupyter/trustyai/ubi9-python-3.12/Pipfile(1 hunks)
🧰 Additional context used
🧠 Learnings (17)
📓 Common learnings
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/test/test_notebook.ipynb:22-29
Timestamp: 2025-07-02T18:27:51.097Z
Learning: jiridanek consistently creates comprehensive follow-up GitHub issues from PR review comments in opendatahub-io/notebooks, turning specific code quality concerns into systematic improvements tracked with proper context, acceptance criteria, and cross-references. Issue #1266 demonstrates this pattern by expanding a specific error handling concern in load_expected_versions() into a repository-wide improvement initiative.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-24T12:01:45.188Z
Learning: jiridanek requested verification of 2024.2 tag package versions against corresponding Pipfiles during PR #1496 review. The analysis revealed that 2024.2 tags contain intentionally frozen older versions (N-1 behavior) while the current PR correctly updates only the N (latest) tags to match Python 3.11 Pipfiles, demonstrating proper understanding of the repository's N-1 version freezing policy.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1379
File: .tekton/odh-workbench-jupyter-datascience-cpu-py312-ubi9-push.yaml:14-17
Timestamp: 2025-07-11T11:15:47.424Z
Learning: jiridanek requested GitHub issue creation for CEL filter problem in datascience workbench Tekton pipelines during PR #1379 review. Issue #1383 was successfully created with comprehensive problem description covering both Python 3.11 and 3.12 pipelines incorrectly watching jupyter/minimal directories instead of jupyter/datascience directories, detailed impact analysis of pipeline execution failures, complete solution with before/after code examples, thorough acceptance criteria for path updates and pipeline triggering verification, implementation notes about repository structure alignment, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1306
File: jupyter/trustyai/ubi9-python-3.12/test/test_notebook.ipynb:112-126
Timestamp: 2025-07-08T13:21:09.150Z
Learning: jiridanek requested GitHub issue creation for notebook linting and formatting improvements during PR #1306 review, specifically to address inconsistent metadata across .ipynb files and implement systematic quality standards. This continues the established pattern of comprehensive issue creation for code quality improvements with detailed problem descriptions, multiple solution options, phased acceptance criteria, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-01T14:46:03.171Z
Learning: jiridanek requested GitHub issue creation for two nitpicks during PR #1588 review: comment wording improvement in ROCm TensorFlow Dockerfile and typo fix in Jupyter DataScience Dockerfile stage header. Issues #1589 and #1590 were successfully created with comprehensive problem descriptions, specific file locations and line numbers, clear before/after solutions, detailed acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/datascience/ubi9-python-3.12/Pipfile:33-34
Timestamp: 2025-07-08T19:26:17.140Z
Learning: jiridanek requested GitHub issue creation for jupyter-client dependency pinning inconsistency during PR #1333 review, specifically asking to note the implications of breaking changes in 9.x versions. Issue #1343 was created with comprehensive problem description covering inconsistent pinning style across all Python 3.12 runtime images, detailed breaking changes analysis (kernel protocol, session management, connection security, API changes, async/await modifications), reproducibility and security impact assessment, multiple solution options with code examples, phased acceptance criteria, implementation guidance, testing approach, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-30T19:44:57.656Z
Learning: In the opendatahub-io/notebooks repository, jiridanek effectively manages comprehensive PR reviews by tracking all feedback as follow-up GitHub issues rather than blocking merge of high-quality implementations. This demonstrates excellent project management practices for balancing current deliverables with future improvements.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-pytorch/ubi9-python-3.12/de-vendor-torch.sh:9-12
Timestamp: 2025-07-08T19:28:15.791Z
Learning: jiridanek requested GitHub issue creation for runtime detection improvement of Python site-packages paths during PR #1333 review. Issue #1344 was created with comprehensive problem description covering hard-coded path fragility across UBI9 distributions, extensive affected files analysis including 4 de-vendor scripts, 30+ Dockerfiles with chmod operations, and 12+ pip.conf configurations, runtime detection solution using sysconfig module, implementation areas breakdown, benefits analysis, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-11T11:16:05.131Z
Learning: jiridanek requested GitHub issue creation for RStudio py311 Tekton push pipelines during PR #1379 review. Issue #1384 was successfully created covering two RStudio variants (CPU and CUDA) found in manifests/base/params-latest.env, with comprehensive problem description, implementation requirements following the same pattern as other workbench pipelines, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Dockerfile.rocm:56-66
Timestamp: 2025-07-02T18:19:49.397Z
Learning: jiridanek consistently creates comprehensive follow-up GitHub issues for security concerns raised during PR reviews in opendatahub-io/notebooks, ensuring systematic tracking and resolution of supply-chain security improvements like GPG signature verification for package repositories.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: TrustyAI's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with TrustyAI's visualization components, but the actual deployed version in requirements.txt shows 3.0.7, indicating incremental testing. The upgrade to 4.0.5 in this PR represents the completion of a gradual migration strategy from the 3.x series after confirming compatibility with Bokeh 3.7.3.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/datascience/ubi9-python-3.11/Pipfile:34-36
Timestamp: 2025-06-28T14:13:27.890Z
Learning: In the opendatahub-io/notebooks repository, the dependency pinning strategy follows a deliberate pattern: core `jupyterlab` package uses exact pinning (==) across all notebook images to ensure UI consistency, while JupyterLab extensions and all server components (jupyter-server, jupyter-server-proxy, jupyter-server-terminals) use compatible release (~=) pinning to allow automatic security updates and bug fixes while maintaining API compatibility.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: The jupyter-bokeh package was previously pinned to version 3.0.5 in the TrustyAI notebook image due to compatibility requirements with TrustyAI components, as indicated by the comment "Should be pinned down to this version in order to be compatible with trustyai" that was removed in this update.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: The jupyter-bokeh pinning to 3.0.5 in TrustyAI notebook image was not due to TrustyAI code compatibility issues, but because the trustyai package itself explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency, causing pip dependency resolution conflicts when trying to upgrade to jupyter-bokeh 4.x.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-23T16:18:42.922Z
Learning: The TensorFlow ROCm Python 3.12 compatibility issue in opendatahub-io/notebooks PR #1259 was caused by using tensorflow-rocm==2.14.0.600 in Pipfile.lock which lacks Python 3.12 wheels, while the Pipfile specifies tensorflow_rocm=~=2.18.1. The solution requires updating Pipfile sources to include https://repo.radeon.com/rocm/manylinux/rocm-rel-6.4/ repository which contains tensorflow_rocm-2.18.1-cp312-cp312-manylinux_2_28_x86_64.whl and regenerating Pipfile.lock using the piplock-refresh GitHub Action.
Learnt from: devcoons
PR: opendatahub-io/notebooks#1494
File: jupyter/tensorflow/ubi9-python-3.11/Pipfile:40-40
Timestamp: 2025-07-23T22:32:21.847Z
Learning: The canonical package name for the Jupyter Bokeh extension on PyPI is `jupyter_bokeh` (with underscore), not `jupyter-bokeh` (with hyphen). PyPI accepts both forms when querying but the official canonical name returned by the API is `jupyter_bokeh`. This should be used in Pipfiles to ensure consistent dependency resolution across the opendatahub-io/notebooks repository.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1325
File: jupyter/datascience/ubi9-python-3.11/Pipfile:32-32
Timestamp: 2025-07-07T14:54:57.907Z
Learning: odh-elyra uses universal wheels (py3-none-any) rather than platform-specific wheels, making it compatible with all supported Python versions through a single wheel file.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.txt and pyproject.toml files, with no open issues tracking jupyter-bokeh 4.x compatibility. This creates an unresolvable pip dependency conflict when trying to upgrade jupyter-bokeh to 4.x in notebook images that include TrustyAI.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: jiridanek's team uses containerized dependency locking for cross-platform compatibility in opendatahub-io/notebooks. They run `pipenv lock` inside UBI9 containers with specific platform arguments (`--platform=linux/amd64 --python-version 3.12`) to avoid host OS dependency conflicts when generating Pipfile.lock files.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/nginx/root/usr/share/container-scripts/nginx/common.sh:1-3
Timestamp: 2025-07-03T12:07:19.365Z
Learning: jiridanek consistently requests GitHub issue creation for technical improvements identified during code reviews in opendatahub-io/notebooks, ensuring systematic tracking of code quality enhancements like shell script portability issues with comprehensive descriptions, solution options, and acceptance criteria.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/utils/process.sh:17-19
Timestamp: 2025-07-03T14:00:00.909Z
Learning: jiridanek efficiently identifies when CodeRabbit review suggestions are already covered by existing comprehensive issues, demonstrating excellent issue management and avoiding duplicate tracking of the same improvements across multiple locations.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1151
File: jupyter/tensorflow/ubi9-python-3.12/test/test_notebook.ipynb:31-34
Timestamp: 2025-07-01T07:03:05.385Z
Learning: jiridanek demonstrates excellent pattern recognition for identifying duplicated code issues across the opendatahub-io/notebooks repository. When spotting a potential problem in test notebooks, he correctly assesses that such patterns are likely replicated across multiple similar files rather than being isolated incidents, leading to more effective systematic solutions.
📚 Learning: in the opendatahub-io/notebooks repository, the dependency pinning strategy follows a deliberate pat...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/datascience/ubi9-python-3.11/Pipfile:34-36
Timestamp: 2025-06-28T14:13:27.890Z
Learning: In the opendatahub-io/notebooks repository, the dependency pinning strategy follows a deliberate pattern: core `jupyterlab` package uses exact pinning (==) across all notebook images to ensure UI consistency, while JupyterLab extensions and all server components (jupyter-server, jupyter-server-proxy, jupyter-server-terminals) use compatible release (~=) pinning to allow automatic security updates and bug fixes while maintaining API compatibility.
Applied to files:
jupyter/minimal/ubi9-python-3.12/Pipfilejupyter/tensorflow/ubi9-python-3.12/Pipfilejupyter/trustyai/ubi9-python-3.11/Pipfilejupyter/rocm/tensorflow/ubi9-python-3.11/Pipfilejupyter/rocm/pytorch/ubi9-python-3.12/Pipfilejupyter/datascience/ubi9-python-3.12/Pipfilejupyter/tensorflow/ubi9-python-3.11/Pipfilejupyter/datascience/ubi9-python-3.11/Pipfilejupyter/minimal/ubi9-python-3.11/Pipfilejupyter/trustyai/ubi9-python-3.12/Pipfilejupyter/pytorch/ubi9-python-3.12/Pipfilejupyter/pytorch/ubi9-python-3.11/Pipfilejupyter/rocm/pytorch/ubi9-python-3.11/Pipfile
📚 Learning: the jupyter-bokeh package was previously pinned to version 3.0.5 in the trustyai notebook image due ...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: The jupyter-bokeh package was previously pinned to version 3.0.5 in the TrustyAI notebook image due to compatibility requirements with TrustyAI components, as indicated by the comment "Should be pinned down to this version in order to be compatible with trustyai" that was removed in this update.
Applied to files:
jupyter/minimal/ubi9-python-3.12/Pipfilejupyter/tensorflow/ubi9-python-3.12/Pipfilejupyter/trustyai/ubi9-python-3.11/Pipfilejupyter/rocm/tensorflow/ubi9-python-3.11/Pipfilejupyter/rocm/pytorch/ubi9-python-3.12/Pipfilejupyter/datascience/ubi9-python-3.12/Pipfilejupyter/tensorflow/ubi9-python-3.11/Pipfilejupyter/datascience/ubi9-python-3.11/Pipfilejupyter/minimal/ubi9-python-3.11/Pipfilejupyter/trustyai/ubi9-python-3.12/Pipfilejupyter/pytorch/ubi9-python-3.12/Pipfilejupyter/pytorch/ubi9-python-3.11/Pipfilejupyter/rocm/pytorch/ubi9-python-3.11/Pipfile
📚 Learning: jiridanek requested verification of 2024.2 tag package versions against corresponding pipfiles durin...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-24T12:01:45.188Z
Learning: jiridanek requested verification of 2024.2 tag package versions against corresponding Pipfiles during PR #1496 review. The analysis revealed that 2024.2 tags contain intentionally frozen older versions (N-1 behavior) while the current PR correctly updates only the N (latest) tags to match Python 3.11 Pipfiles, demonstrating proper understanding of the repository's N-1 version freezing policy.
Applied to files:
jupyter/minimal/ubi9-python-3.12/Pipfilejupyter/tensorflow/ubi9-python-3.12/Pipfilejupyter/trustyai/ubi9-python-3.11/Pipfilejupyter/rocm/tensorflow/ubi9-python-3.11/Pipfilejupyter/rocm/pytorch/ubi9-python-3.12/Pipfilejupyter/datascience/ubi9-python-3.12/Pipfilejupyter/tensorflow/ubi9-python-3.11/Pipfilejupyter/datascience/ubi9-python-3.11/Pipfilejupyter/minimal/ubi9-python-3.11/Pipfilejupyter/trustyai/ubi9-python-3.12/Pipfilejupyter/pytorch/ubi9-python-3.12/Pipfilejupyter/pytorch/ubi9-python-3.11/Pipfilejupyter/rocm/pytorch/ubi9-python-3.11/Pipfile
📚 Learning: the jupyter-bokeh pinning to 3.0.5 in trustyai notebook image was not due to trustyai code compatibi...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: The jupyter-bokeh pinning to 3.0.5 in TrustyAI notebook image was not due to TrustyAI code compatibility issues, but because the trustyai package itself explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency, causing pip dependency resolution conflicts when trying to upgrade to jupyter-bokeh 4.x.
Applied to files:
jupyter/minimal/ubi9-python-3.12/Pipfilejupyter/tensorflow/ubi9-python-3.12/Pipfilejupyter/trustyai/ubi9-python-3.11/Pipfilejupyter/rocm/tensorflow/ubi9-python-3.11/Pipfilejupyter/rocm/pytorch/ubi9-python-3.12/Pipfilejupyter/datascience/ubi9-python-3.12/Pipfilejupyter/tensorflow/ubi9-python-3.11/Pipfilejupyter/datascience/ubi9-python-3.11/Pipfilejupyter/minimal/ubi9-python-3.11/Pipfilejupyter/trustyai/ubi9-python-3.12/Pipfilejupyter/pytorch/ubi9-python-3.12/Pipfilejupyter/pytorch/ubi9-python-3.11/Pipfilejupyter/rocm/pytorch/ubi9-python-3.11/Pipfile
📚 Learning: the tensorflow rocm python 3.12 compatibility issue in opendatahub-io/notebooks pr #1259 was caused ...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-23T16:18:42.922Z
Learning: The TensorFlow ROCm Python 3.12 compatibility issue in opendatahub-io/notebooks PR #1259 was caused by using tensorflow-rocm==2.14.0.600 in Pipfile.lock which lacks Python 3.12 wheels, while the Pipfile specifies tensorflow_rocm=~=2.18.1. The solution requires updating Pipfile sources to include https://repo.radeon.com/rocm/manylinux/rocm-rel-6.4/ repository which contains tensorflow_rocm-2.18.1-cp312-cp312-manylinux_2_28_x86_64.whl and regenerating Pipfile.lock using the piplock-refresh GitHub Action.
Applied to files:
jupyter/minimal/ubi9-python-3.12/Pipfilejupyter/tensorflow/ubi9-python-3.12/Pipfilejupyter/trustyai/ubi9-python-3.11/Pipfilejupyter/rocm/tensorflow/ubi9-python-3.11/Pipfilejupyter/rocm/pytorch/ubi9-python-3.12/Pipfilejupyter/datascience/ubi9-python-3.12/Pipfilejupyter/tensorflow/ubi9-python-3.11/Pipfilejupyter/datascience/ubi9-python-3.11/Pipfilejupyter/minimal/ubi9-python-3.11/Pipfilejupyter/trustyai/ubi9-python-3.12/Pipfilejupyter/pytorch/ubi9-python-3.12/Pipfilejupyter/pytorch/ubi9-python-3.11/Pipfilejupyter/rocm/pytorch/ubi9-python-3.11/Pipfile
📚 Learning: jiridanek's team uses containerized dependency locking for cross-platform compatibility in opendatah...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: jiridanek's team uses containerized dependency locking for cross-platform compatibility in opendatahub-io/notebooks. They run `pipenv lock` inside UBI9 containers with specific platform arguments (`--platform=linux/amd64 --python-version 3.12`) to avoid host OS dependency conflicts when generating Pipfile.lock files.
Applied to files:
jupyter/minimal/ubi9-python-3.12/Pipfilejupyter/tensorflow/ubi9-python-3.12/Pipfilejupyter/trustyai/ubi9-python-3.11/Pipfilejupyter/rocm/tensorflow/ubi9-python-3.11/Pipfilejupyter/rocm/pytorch/ubi9-python-3.12/Pipfilejupyter/datascience/ubi9-python-3.12/Pipfilejupyter/tensorflow/ubi9-python-3.11/Pipfilejupyter/datascience/ubi9-python-3.11/Pipfilejupyter/minimal/ubi9-python-3.11/Pipfilejupyter/trustyai/ubi9-python-3.12/Pipfilejupyter/pytorch/ubi9-python-3.12/Pipfilejupyter/pytorch/ubi9-python-3.11/Pipfilejupyter/rocm/pytorch/ubi9-python-3.11/Pipfile
📚 Learning: trustyai's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with trustyai's visua...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: TrustyAI's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with TrustyAI's visualization components, but the actual deployed version in requirements.txt shows 3.0.7, indicating incremental testing. The upgrade to 4.0.5 in this PR represents the completion of a gradual migration strategy from the 3.x series after confirming compatibility with Bokeh 3.7.3.
Applied to files:
jupyter/minimal/ubi9-python-3.12/Pipfilejupyter/tensorflow/ubi9-python-3.12/Pipfilejupyter/trustyai/ubi9-python-3.11/Pipfilejupyter/rocm/tensorflow/ubi9-python-3.11/Pipfilejupyter/rocm/pytorch/ubi9-python-3.12/Pipfilejupyter/datascience/ubi9-python-3.12/Pipfilejupyter/tensorflow/ubi9-python-3.11/Pipfilejupyter/datascience/ubi9-python-3.11/Pipfilejupyter/minimal/ubi9-python-3.11/Pipfilejupyter/trustyai/ubi9-python-3.12/Pipfilejupyter/pytorch/ubi9-python-3.12/Pipfilejupyter/pytorch/ubi9-python-3.11/Pipfilejupyter/rocm/pytorch/ubi9-python-3.11/Pipfile
📚 Learning: jiridanek requested github issue creation for jupyter-client dependency pinning inconsistency during...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/datascience/ubi9-python-3.12/Pipfile:33-34
Timestamp: 2025-07-08T19:26:17.140Z
Learning: jiridanek requested GitHub issue creation for jupyter-client dependency pinning inconsistency during PR #1333 review, specifically asking to note the implications of breaking changes in 9.x versions. Issue #1343 was created with comprehensive problem description covering inconsistent pinning style across all Python 3.12 runtime images, detailed breaking changes analysis (kernel protocol, session management, connection security, API changes, async/await modifications), reproducibility and security impact assessment, multiple solution options with code examples, phased acceptance criteria, implementation guidance, testing approach, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
jupyter/minimal/ubi9-python-3.12/Pipfilejupyter/datascience/ubi9-python-3.12/Pipfilejupyter/datascience/ubi9-python-3.11/Pipfilejupyter/minimal/ubi9-python-3.11/Pipfilejupyter/trustyai/ubi9-python-3.12/Pipfile
📚 Learning: the python 3.11 infrastructure for rocm tensorflow images in opendatahub-io/notebooks is already pro...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Pipfile:13-15
Timestamp: 2025-07-03T07:03:45.020Z
Learning: The Python 3.11 infrastructure for ROCm TensorFlow images in opendatahub-io/notebooks is already properly configured in the Makefile with both BASE_DIRS entries for Pipfile lock renewals and all-images targets for CI builds, requiring only commenting out the corresponding Python 3.12 entries when downgrading due to wheel availability issues.
Applied to files:
jupyter/minimal/ubi9-python-3.12/Pipfilejupyter/tensorflow/ubi9-python-3.12/Pipfilejupyter/trustyai/ubi9-python-3.11/Pipfilejupyter/rocm/tensorflow/ubi9-python-3.11/Pipfilejupyter/rocm/pytorch/ubi9-python-3.12/Pipfilejupyter/tensorflow/ubi9-python-3.11/Pipfilejupyter/minimal/ubi9-python-3.11/Pipfilejupyter/pytorch/ubi9-python-3.12/Pipfilejupyter/pytorch/ubi9-python-3.11/Pipfilejupyter/rocm/pytorch/ubi9-python-3.11/Pipfile
📚 Learning: trustyai explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.tx...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.txt and pyproject.toml files, with no open issues tracking jupyter-bokeh 4.x compatibility. This creates an unresolvable pip dependency conflict when trying to upgrade jupyter-bokeh to 4.x in notebook images that include TrustyAI.
Applied to files:
jupyter/minimal/ubi9-python-3.12/Pipfilejupyter/tensorflow/ubi9-python-3.12/Pipfilejupyter/trustyai/ubi9-python-3.11/Pipfilejupyter/rocm/tensorflow/ubi9-python-3.11/Pipfilejupyter/rocm/pytorch/ubi9-python-3.12/Pipfilejupyter/datascience/ubi9-python-3.12/Pipfilejupyter/tensorflow/ubi9-python-3.11/Pipfilejupyter/datascience/ubi9-python-3.11/Pipfilejupyter/minimal/ubi9-python-3.11/Pipfilejupyter/trustyai/ubi9-python-3.12/Pipfilejupyter/pytorch/ubi9-python-3.12/Pipfilejupyter/pytorch/ubi9-python-3.11/Pipfilejupyter/rocm/pytorch/ubi9-python-3.11/Pipfile
📚 Learning: trustyai 0.6.1 (latest version as of june 2025) has a hard dependency constraint on jupyter-bokeh~=3...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI 0.6.1 (latest version as of June 2025) has a hard dependency constraint on jupyter-bokeh~=3.0.5, preventing upgrades to jupyter-bokeh 4.x in notebook images that include TrustyAI. This requires either waiting for TrustyAI to update their dependency or excluding TrustyAI from jupyter-bokeh upgrades.
Applied to files:
jupyter/minimal/ubi9-python-3.12/Pipfilejupyter/tensorflow/ubi9-python-3.12/Pipfilejupyter/trustyai/ubi9-python-3.11/Pipfilejupyter/rocm/tensorflow/ubi9-python-3.11/Pipfilejupyter/rocm/pytorch/ubi9-python-3.12/Pipfilejupyter/datascience/ubi9-python-3.12/Pipfilejupyter/tensorflow/ubi9-python-3.11/Pipfilejupyter/datascience/ubi9-python-3.11/Pipfilejupyter/minimal/ubi9-python-3.11/Pipfilejupyter/trustyai/ubi9-python-3.12/Pipfilejupyter/pytorch/ubi9-python-3.12/Pipfilejupyter/pytorch/ubi9-python-3.11/Pipfilejupyter/rocm/pytorch/ubi9-python-3.11/Pipfile
📚 Learning: odh-elyra uses universal wheels (py3-none-any) rather than platform-specific wheels, making it compa...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1325
File: jupyter/datascience/ubi9-python-3.11/Pipfile:32-32
Timestamp: 2025-07-07T14:54:57.907Z
Learning: odh-elyra uses universal wheels (py3-none-any) rather than platform-specific wheels, making it compatible with all supported Python versions through a single wheel file.
Applied to files:
jupyter/tensorflow/ubi9-python-3.12/Pipfilejupyter/trustyai/ubi9-python-3.11/Pipfilejupyter/rocm/tensorflow/ubi9-python-3.11/Pipfilejupyter/rocm/pytorch/ubi9-python-3.12/Pipfilejupyter/datascience/ubi9-python-3.12/Pipfilejupyter/tensorflow/ubi9-python-3.11/Pipfilejupyter/datascience/ubi9-python-3.11/Pipfilejupyter/trustyai/ubi9-python-3.12/Pipfilejupyter/pytorch/ubi9-python-3.12/Pipfilejupyter/pytorch/ubi9-python-3.11/Pipfilejupyter/rocm/pytorch/ubi9-python-3.11/Pipfile
📚 Learning: the canonical package name for the jupyter bokeh extension on pypi is `jupyter_bokeh` (with undersco...
Learnt from: devcoons
PR: opendatahub-io/notebooks#1494
File: jupyter/tensorflow/ubi9-python-3.11/Pipfile:40-40
Timestamp: 2025-07-23T22:32:21.847Z
Learning: The canonical package name for the Jupyter Bokeh extension on PyPI is `jupyter_bokeh` (with underscore), not `jupyter-bokeh` (with hyphen). PyPI accepts both forms when querying but the official canonical name returned by the API is `jupyter_bokeh`. This should be used in Pipfiles to ensure consistent dependency resolution across the opendatahub-io/notebooks repository.
Applied to files:
jupyter/tensorflow/ubi9-python-3.12/Pipfilejupyter/trustyai/ubi9-python-3.11/Pipfilejupyter/rocm/tensorflow/ubi9-python-3.11/Pipfilejupyter/rocm/pytorch/ubi9-python-3.12/Pipfilejupyter/datascience/ubi9-python-3.12/Pipfilejupyter/tensorflow/ubi9-python-3.11/Pipfilejupyter/datascience/ubi9-python-3.11/Pipfilejupyter/trustyai/ubi9-python-3.12/Pipfilejupyter/pytorch/ubi9-python-3.12/Pipfilejupyter/pytorch/ubi9-python-3.11/Pipfilejupyter/rocm/pytorch/ubi9-python-3.11/Pipfile
📚 Learning: tensorflow_rocm package versions 2.12.1.570 through 2.14.0.600 do not provide python 3.12 wheels (cp...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Pipfile:13-15
Timestamp: 2025-07-03T07:03:45.020Z
Learning: tensorflow_rocm package versions 2.12.1.570 through 2.14.0.600 do not provide Python 3.12 wheels (cp312) on PyPI, causing Pipfile lock failures when attempting to create Python 3.12-based ROCm TensorFlow notebook images in opendatahub-io/notebooks.
Applied to files:
jupyter/rocm/tensorflow/ubi9-python-3.11/Pipfilejupyter/rocm/pytorch/ubi9-python-3.12/Pipfilejupyter/rocm/pytorch/ubi9-python-3.11/Pipfile
📚 Learning: in the opendatahub-io/notebooks repository, there is a known issue with missing `runtimes/rocm/pytor...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: In the opendatahub-io/notebooks repository, there is a known issue with missing `runtimes/rocm/pytorch/ubi9-python-3.11/kustomize/base/kustomization.yaml` file that causes rocm runtime tests to fail with "no such file or directory" error. This is tracked in JIRA RHOAIENG-22044 and was intended to be fixed in PR #1015.
Applied to files:
jupyter/rocm/tensorflow/ubi9-python-3.11/Pipfilejupyter/rocm/pytorch/ubi9-python-3.12/Pipfilejupyter/rocm/pytorch/ubi9-python-3.11/Pipfile
📚 Learning: jiridanek requested github issue creation for tensorflow_rocm python 3.12 compatibility problem duri...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-tensorflow/ubi9-python-3.12/Pipfile:13-15
Timestamp: 2025-07-09T08:07:24.937Z
Learning: jiridanek requested GitHub issue creation for tensorflow_rocm Python 3.12 compatibility problem during PR #1333 review. Issue #1354 was successfully created with comprehensive problem description covering missing cp312 wheels causing build failures, three solution options (upstream TensorFlow, Python 3.11 only, custom build), clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
jupyter/rocm/tensorflow/ubi9-python-3.11/Pipfilejupyter/rocm/pytorch/ubi9-python-3.12/Pipfilejupyter/rocm/pytorch/ubi9-python-3.11/Pipfile
🔇 Additional comments (14)
jupyter/tensorflow/ubi9-python-3.12/Pipfile (1)
37-37: Upgrade to odh-elyra 4.2.3 – check JL compatibility
odh-elyra 4.2.3claims JupyterLab 4.2 support, but its 4.2.3 wheel was published only days ago. If you haven’t already, sanity-test a notebook pipeline to confirm no regressions.jupyter/trustyai/ubi9-python-3.11/Pipfile (2)
46-46: elyra bump acknowledged – validate with TrustyAITrustyAI images carry several strict pins (numpy, matplotlib, etc.). Although Elyra usually remains independent, run a quick startup test to ensure no hidden conflicts.
53-53: Lock file refresh required for jupyterlab-gitPlease regenerate the lock to capture the 0.51.1 version.
jupyter/pytorch/ubi9-python-3.12/Pipfile (2)
42-42: elyra 4.2.3 – LGTMNo immediate concerns; the universal wheel should install fine on CUDA images.
49-49: Lock refresh for jupyterlab-gitSame note as above – ensure Pipfile.lock is in sync.
jupyter/rocm/tensorflow/ubi9-python-3.11/Pipfile (2)
39-39: elyra bump OK (Python 3.11)No issues spotted; wheel is py3-none-any.
46-46: Update lock file for git extensionRegenerate the lock so 0.51.1 is pinned; prevents inadvertent downgrade at build time.
jupyter/datascience/ubi9-python-3.11/Pipfile (1)
32-39: Confirm Pipfile.lock was regenerated after version bumps
odh-elyraandjupyterlab-githave been bumped (Lines 32 & 39). Please double-check that:
- the corresponding
Pipfile.lockfor this image was rebuilt in the same containerized environment (UBI9 +pipenv lock --platform=linux/amd64 --python-version 3.11),- CI still resolves these exact versions with no transitive conflicts.
This keeps the lockfile and runtime image in sync and avoids surprises during build.
jupyter/pytorch/ubi9-python-3.11/Pipfile (1)
42-49: Sync lockfile with newodh-elyra/jupyterlab-gitpinsThe same two packages were upgraded here. Please ensure the PyTorch image’s
Pipfile.lockwas refreshed and that CUDA wheels (from the extrapytorchindex) continue to resolve cleanly together with the new versions.jupyter/datascience/ubi9-python-3.12/Pipfile (1)
32-39: Re-lock after upgrading JupyterLab extensionsAfter bumping
odh-elyraandjupyterlab-git, regenerate the 3.12 lockfile with the usual containerized command to prevent drift between Pipfile and lock.jupyter/tensorflow/ubi9-python-3.11/Pipfile (1)
36-44: Lockfile refresh needed for TensorFlow imagePlease rebuild
Pipfile.lockso the TensorFlow CUDA stack is tested against the newodh-elyra 4.2.3andjupyterlab-git 0.51.1pins.jupyter/trustyai/ubi9-python-3.12/Pipfile (1)
46-53: Verify TrustyAI compatibility after Elyra / Git bumpsAlthough
trustyaiconstrains several deps, Elyra & JupyterLab-Git upgrades usually stay API-compatible. Still, rerunpipenv lockand a quick notebook smoke-test for this image to ensure no hidden conflicts with TrustyAI’s tight pins (jupyter-bokeh 3.0.5, specific pandas/numpy/matplotlib, …).jupyter/rocm/pytorch/ubi9-python-3.12/Pipfile (1)
44-51: Uniform odh-elyra and jupyterlab-git versions across Pipfiles verified
All Pipfiles referenceodh-elyra ==4.2.3andjupyterlab-git ~=0.51.1; no stray Pipfiles remain with older versions.jupyter/minimal/ubi9-python-3.11/Pipfile (1)
15-15: Minimal image bump acknowledged – run consistency check
jupyterlab-gitis now~=0.51.1; minimal images deliberately omitodh-elyra, so no action there.
Run the same grep as above to ensure every Pipfile was updated.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
jupyter/tensorflow/ubi9-python-3.11/requirements.txt (1)
1064-1066: Keras ≥3 in a TensorFlow 2.x image can shadowtf.kerasInstalling standalone
keras==3.11.1next totensorflow==2.18.1means both
import keras(Keras-3) andimport tensorflow.keras(TF-Keras) coexist.
Accidentalimport kerasin user notebooks silently switches to the new API,
which is not 100 % compatible with TF-Keras.If the image does not intentionally expose Keras-3, consider removing the wheel
or setting the default backend explicitly:ENV KERAS_BACKEND="tensorflow"to reduce surprises.
jupyter/rocm/tensorflow/ubi9-python-3.11/requirements.txt (1)
2005-2013: Optional: disablepy-spyin production images
py-spyis a fantastic profiler but it injects the ptrace capability at runtime, which some hardened clusters block.
If the ROCm notebook image is meant only for end-users, consider moving this tool to dev-only requirements.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (14)
codeserver/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockjupyter/datascience/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockjupyter/minimal/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockjupyter/pytorch/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockjupyter/rocm/pytorch/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockjupyter/rocm/tensorflow/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockjupyter/tensorflow/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockjupyter/trustyai/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockruntimes/datascience/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockruntimes/minimal/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockruntimes/pytorch/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockruntimes/rocm-pytorch/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockruntimes/rocm-tensorflow/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lockruntimes/tensorflow/ubi9-python-3.11/Pipfile.lockis excluded by!**/*.lock
📒 Files selected for processing (14)
codeserver/ubi9-python-3.11/requirements.txt(2 hunks)jupyter/datascience/ubi9-python-3.11/requirements.txt(6 hunks)jupyter/minimal/ubi9-python-3.11/requirements.txt(2 hunks)jupyter/pytorch/ubi9-python-3.11/requirements.txt(6 hunks)jupyter/rocm/pytorch/ubi9-python-3.11/requirements.txt(6 hunks)jupyter/rocm/tensorflow/ubi9-python-3.11/requirements.txt(6 hunks)jupyter/tensorflow/ubi9-python-3.11/requirements.txt(7 hunks)jupyter/trustyai/ubi9-python-3.11/requirements.txt(6 hunks)runtimes/datascience/ubi9-python-3.11/requirements.txt(3 hunks)runtimes/minimal/ubi9-python-3.11/requirements.txt(1 hunks)runtimes/pytorch/ubi9-python-3.11/requirements.txt(3 hunks)runtimes/rocm-pytorch/ubi9-python-3.11/requirements.txt(3 hunks)runtimes/rocm-tensorflow/ubi9-python-3.11/requirements.txt(3 hunks)runtimes/tensorflow/ubi9-python-3.11/requirements.txt(4 hunks)
✅ Files skipped from review due to trivial changes (11)
- runtimes/minimal/ubi9-python-3.11/requirements.txt
- codeserver/ubi9-python-3.11/requirements.txt
- jupyter/minimal/ubi9-python-3.11/requirements.txt
- runtimes/datascience/ubi9-python-3.11/requirements.txt
- runtimes/rocm-tensorflow/ubi9-python-3.11/requirements.txt
- runtimes/tensorflow/ubi9-python-3.11/requirements.txt
- runtimes/rocm-pytorch/ubi9-python-3.11/requirements.txt
- runtimes/pytorch/ubi9-python-3.11/requirements.txt
- jupyter/datascience/ubi9-python-3.11/requirements.txt
- jupyter/trustyai/ubi9-python-3.11/requirements.txt
- jupyter/pytorch/ubi9-python-3.11/requirements.txt
🧰 Additional context used
🧠 Learnings (23)
📓 Common learnings
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/test/test_notebook.ipynb:22-29
Timestamp: 2025-07-02T18:27:51.097Z
Learning: jiridanek consistently creates comprehensive follow-up GitHub issues from PR review comments in opendatahub-io/notebooks, turning specific code quality concerns into systematic improvements tracked with proper context, acceptance criteria, and cross-references. Issue #1266 demonstrates this pattern by expanding a specific error handling concern in load_expected_versions() into a repository-wide improvement initiative.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1379
File: .tekton/odh-workbench-jupyter-datascience-cpu-py312-ubi9-push.yaml:14-17
Timestamp: 2025-07-11T11:15:47.424Z
Learning: jiridanek requested GitHub issue creation for CEL filter problem in datascience workbench Tekton pipelines during PR #1379 review. Issue #1383 was successfully created with comprehensive problem description covering both Python 3.11 and 3.12 pipelines incorrectly watching jupyter/minimal directories instead of jupyter/datascience directories, detailed impact analysis of pipeline execution failures, complete solution with before/after code examples, thorough acceptance criteria for path updates and pipeline triggering verification, implementation notes about repository structure alignment, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1306
File: jupyter/trustyai/ubi9-python-3.12/test/test_notebook.ipynb:112-126
Timestamp: 2025-07-08T13:21:09.150Z
Learning: jiridanek requested GitHub issue creation for notebook linting and formatting improvements during PR #1306 review, specifically to address inconsistent metadata across .ipynb files and implement systematic quality standards. This continues the established pattern of comprehensive issue creation for code quality improvements with detailed problem descriptions, multiple solution options, phased acceptance criteria, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-24T12:01:45.188Z
Learning: jiridanek requested verification of 2024.2 tag package versions against corresponding Pipfiles during PR #1496 review. The analysis revealed that 2024.2 tags contain intentionally frozen older versions (N-1 behavior) while the current PR correctly updates only the N (latest) tags to match Python 3.11 Pipfiles, demonstrating proper understanding of the repository's N-1 version freezing policy.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-01T14:46:03.215Z
Learning: jiridanek requested GitHub issue creation for two nitpicks during PR #1588 review: comment wording improvement in ROCm TensorFlow Dockerfile and typo fix in Jupyter DataScience Dockerfile stage header. Issues #1589 and #1590 were successfully created with comprehensive problem descriptions, specific file locations and line numbers, clear before/after solutions, detailed acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/datascience/ubi9-python-3.12/Pipfile:33-34
Timestamp: 2025-07-08T19:26:17.140Z
Learning: jiridanek requested GitHub issue creation for jupyter-client dependency pinning inconsistency during PR #1333 review, specifically asking to note the implications of breaking changes in 9.x versions. Issue #1343 was created with comprehensive problem description covering inconsistent pinning style across all Python 3.12 runtime images, detailed breaking changes analysis (kernel protocol, session management, connection security, API changes, async/await modifications), reproducibility and security impact assessment, multiple solution options with code examples, phased acceptance criteria, implementation guidance, testing approach, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-11T11:16:05.131Z
Learning: jiridanek requested GitHub issue creation for RStudio py311 Tekton push pipelines during PR #1379 review. Issue #1384 was successfully created covering two RStudio variants (CPU and CUDA) found in manifests/base/params-latest.env, with comprehensive problem description, implementation requirements following the same pattern as other workbench pipelines, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1325
File: jupyter/pytorch/ubi9-python-3.12/Pipfile:42-42
Timestamp: 2025-07-09T14:22:14.553Z
Learning: jiridanek requested GitHub issue creation for Pipfile.lock verification script implementation during PR #1325 review, specifically to systematize the manual verification process for dependency version consistency across all lock files using jq. Issue #1367 was created with comprehensive problem description covering manual verification challenges, detailed solution with jq-based verification script, enhanced features for CI integration, clear acceptance criteria, implementation areas breakdown, benefits analysis, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-pytorch/ubi9-python-3.12/de-vendor-torch.sh:9-12
Timestamp: 2025-07-08T19:28:15.791Z
Learning: jiridanek requested GitHub issue creation for runtime detection improvement of Python site-packages paths during PR #1333 review. Issue #1344 was created with comprehensive problem description covering hard-coded path fragility across UBI9 distributions, extensive affected files analysis including 4 de-vendor scripts, 30+ Dockerfiles with chmod operations, and 12+ pip.conf configurations, runtime detection solution using sysconfig module, implementation areas breakdown, benefits analysis, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Dockerfile.rocm:56-66
Timestamp: 2025-07-02T18:19:49.397Z
Learning: jiridanek consistently creates comprehensive follow-up GitHub issues for security concerns raised during PR reviews in opendatahub-io/notebooks, ensuring systematic tracking and resolution of supply-chain security improvements like GPG signature verification for package repositories.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: TrustyAI's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with TrustyAI's visualization components, but the actual deployed version in requirements.txt shows 3.0.7, indicating incremental testing. The upgrade to 4.0.5 in this PR represents the completion of a gradual migration strategy from the 3.x series after confirming compatibility with Bokeh 3.7.3.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: The jupyter-bokeh package was previously pinned to version 3.0.5 in the TrustyAI notebook image due to compatibility requirements with TrustyAI components, as indicated by the comment "Should be pinned down to this version in order to be compatible with trustyai" that was removed in this update.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/datascience/ubi9-python-3.11/Pipfile:34-36
Timestamp: 2025-06-28T14:13:27.890Z
Learning: In the opendatahub-io/notebooks repository, the dependency pinning strategy follows a deliberate pattern: core `jupyterlab` package uses exact pinning (==) across all notebook images to ensure UI consistency, while JupyterLab extensions and all server components (jupyter-server, jupyter-server-proxy, jupyter-server-terminals) use compatible release (~=) pinning to allow automatic security updates and bug fixes while maintaining API compatibility.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-23T16:18:42.922Z
Learning: The TensorFlow ROCm Python 3.12 compatibility issue in opendatahub-io/notebooks PR #1259 was caused by using tensorflow-rocm==2.14.0.600 in Pipfile.lock which lacks Python 3.12 wheels, while the Pipfile specifies tensorflow_rocm=~=2.18.1. The solution requires updating Pipfile sources to include https://repo.radeon.com/rocm/manylinux/rocm-rel-6.4/ repository which contains tensorflow_rocm-2.18.1-cp312-cp312-manylinux_2_28_x86_64.whl and regenerating Pipfile.lock using the piplock-refresh GitHub Action.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.txt and pyproject.toml files, with no open issues tracking jupyter-bokeh 4.x compatibility. This creates an unresolvable pip dependency conflict when trying to upgrade jupyter-bokeh to 4.x in notebook images that include TrustyAI.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: jiridanek's team uses containerized dependency locking for cross-platform compatibility in opendatahub-io/notebooks. They run `pipenv lock` inside UBI9 containers with specific platform arguments (`--platform=linux/amd64 --python-version 3.12`) to avoid host OS dependency conflicts when generating Pipfile.lock files.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: The jupyter-bokeh pinning to 3.0.5 in TrustyAI notebook image was not due to TrustyAI code compatibility issues, but because the trustyai package itself explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency, causing pip dependency resolution conflicts when trying to upgrade to jupyter-bokeh 4.x.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1519
File: jupyter/pytorch+llmcompressor/ubi9-python-3.11/runtime-images/llmcompressor-pytorch-ubi9-py311.json:2-9
Timestamp: 2025-07-29T16:00:31.637Z
Learning: jiridanek indicated that the current practice for runtime-images JSON files in opendatahub-io/notebooks has changed significantly from the SHA256 digest pinning pattern, and that rebasing PR #1519 would reveal the new practice which is "something completely different" from the existing pattern.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/nginx/root/usr/share/container-scripts/nginx/common.sh:1-3
Timestamp: 2025-07-03T12:07:19.365Z
Learning: jiridanek consistently requests GitHub issue creation for technical improvements identified during code reviews in opendatahub-io/notebooks, ensuring systematic tracking of code quality enhancements like shell script portability issues with comprehensive descriptions, solution options, and acceptance criteria.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/utils/process.sh:17-19
Timestamp: 2025-07-03T14:00:00.909Z
Learning: jiridanek efficiently identifies when CodeRabbit review suggestions are already covered by existing comprehensive issues, demonstrating excellent issue management and avoiding duplicate tracking of the same improvements across multiple locations.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1151
File: jupyter/tensorflow/ubi9-python-3.12/test/test_notebook.ipynb:31-34
Timestamp: 2025-07-01T07:03:05.385Z
Learning: jiridanek demonstrates excellent pattern recognition for identifying duplicated code issues across the opendatahub-io/notebooks repository. When spotting a potential problem in test notebooks, he correctly assesses that such patterns are likely replicated across multiple similar files rather than being isolated incidents, leading to more effective systematic solutions.
📚 Learning: the tensorflow rocm python 3.12 compatibility issue in opendatahub-io/notebooks pr #1259 was caused ...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-23T16:18:42.922Z
Learning: The TensorFlow ROCm Python 3.12 compatibility issue in opendatahub-io/notebooks PR #1259 was caused by using tensorflow-rocm==2.14.0.600 in Pipfile.lock which lacks Python 3.12 wheels, while the Pipfile specifies tensorflow_rocm=~=2.18.1. The solution requires updating Pipfile sources to include https://repo.radeon.com/rocm/manylinux/rocm-rel-6.4/ repository which contains tensorflow_rocm-2.18.1-cp312-cp312-manylinux_2_28_x86_64.whl and regenerating Pipfile.lock using the piplock-refresh GitHub Action.
Applied to files:
jupyter/rocm/tensorflow/ubi9-python-3.11/requirements.txtjupyter/rocm/pytorch/ubi9-python-3.11/requirements.txtjupyter/tensorflow/ubi9-python-3.11/requirements.txt
📚 Learning: jiridanek requested github issue creation for tensorflow_rocm python 3.12 compatibility problem duri...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-tensorflow/ubi9-python-3.12/Pipfile:13-15
Timestamp: 2025-07-09T08:07:24.937Z
Learning: jiridanek requested GitHub issue creation for tensorflow_rocm Python 3.12 compatibility problem during PR #1333 review. Issue #1354 was successfully created with comprehensive problem description covering missing cp312 wheels causing build failures, three solution options (upstream TensorFlow, Python 3.11 only, custom build), clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
jupyter/rocm/tensorflow/ubi9-python-3.11/requirements.txtjupyter/rocm/pytorch/ubi9-python-3.11/requirements.txtjupyter/tensorflow/ubi9-python-3.11/requirements.txt
📚 Learning: tensorflow_rocm package versions 2.12.1.570 through 2.14.0.600 do not provide python 3.12 wheels (cp...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Pipfile:13-15
Timestamp: 2025-07-03T07:03:45.020Z
Learning: tensorflow_rocm package versions 2.12.1.570 through 2.14.0.600 do not provide Python 3.12 wheels (cp312) on PyPI, causing Pipfile lock failures when attempting to create Python 3.12-based ROCm TensorFlow notebook images in opendatahub-io/notebooks.
Applied to files:
jupyter/rocm/tensorflow/ubi9-python-3.11/requirements.txtjupyter/rocm/pytorch/ubi9-python-3.11/requirements.txtjupyter/tensorflow/ubi9-python-3.11/requirements.txt
📚 Learning: the python 3.11 infrastructure for rocm tensorflow images in opendatahub-io/notebooks is already pro...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Pipfile:13-15
Timestamp: 2025-07-03T07:03:45.020Z
Learning: The Python 3.11 infrastructure for ROCm TensorFlow images in opendatahub-io/notebooks is already properly configured in the Makefile with both BASE_DIRS entries for Pipfile lock renewals and all-images targets for CI builds, requiring only commenting out the corresponding Python 3.12 entries when downgrading due to wheel availability issues.
Applied to files:
jupyter/rocm/tensorflow/ubi9-python-3.11/requirements.txtjupyter/rocm/pytorch/ubi9-python-3.11/requirements.txtjupyter/tensorflow/ubi9-python-3.11/requirements.txt
📚 Learning: trustyai's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with trustyai's visua...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: TrustyAI's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with TrustyAI's visualization components, but the actual deployed version in requirements.txt shows 3.0.7, indicating incremental testing. The upgrade to 4.0.5 in this PR represents the completion of a gradual migration strategy from the 3.x series after confirming compatibility with Bokeh 3.7.3.
Applied to files:
jupyter/rocm/tensorflow/ubi9-python-3.11/requirements.txtjupyter/rocm/pytorch/ubi9-python-3.11/requirements.txtjupyter/tensorflow/ubi9-python-3.11/requirements.txt
📚 Learning: rocm is not supported by upstream tensorflow, unlike cuda. rocm support requires the specialized ten...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Pipfile:13-15
Timestamp: 2025-07-14T15:36:29.815Z
Learning: ROCm is not supported by upstream TensorFlow, unlike CUDA. ROCm support requires the specialized tensorflow_rocm package, which creates a dependency challenge for Python 3.12 environments since tensorflow_rocm lacks Python 3.12 wheels while regular TensorFlow lacks ROCm support.
Applied to files:
jupyter/rocm/tensorflow/ubi9-python-3.11/requirements.txt
📚 Learning: tensorflow_rocm package has no python 3.12 or 3.13 wheel support as of july 2025, with the latest ve...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Pipfile:13-15
Timestamp: 2025-07-03T07:05:33.329Z
Learning: tensorflow_rocm package has no Python 3.12 or 3.13 wheel support as of July 2025, with the latest version 2.14.0.600 only supporting Python 3.9, 3.10, and 3.11. The tensorflow-rocm upstream project appears abandoned with the last release in 2019. For Python 3.12+ ROCm TensorFlow environments, regular TensorFlow 2.18+ with runtime ROCm configuration is the recommended and industry-standard approach, as modern TensorFlow automatically detects and utilizes ROCm when properly installed.
Applied to files:
jupyter/rocm/tensorflow/ubi9-python-3.11/requirements.txtjupyter/rocm/pytorch/ubi9-python-3.11/requirements.txtjupyter/tensorflow/ubi9-python-3.11/requirements.txt
📚 Learning: the jupyter-bokeh package was previously pinned to version 3.0.5 in the trustyai notebook image due ...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: The jupyter-bokeh package was previously pinned to version 3.0.5 in the TrustyAI notebook image due to compatibility requirements with TrustyAI components, as indicated by the comment "Should be pinned down to this version in order to be compatible with trustyai" that was removed in this update.
Applied to files:
jupyter/rocm/tensorflow/ubi9-python-3.11/requirements.txtjupyter/rocm/pytorch/ubi9-python-3.11/requirements.txtjupyter/tensorflow/ubi9-python-3.11/requirements.txt
📚 Learning: tensorflow_rocm package has no python 3.12 or 3.13 wheel support as of july 2025, with the latest ve...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Pipfile:13-15
Timestamp: 2025-07-03T07:05:33.329Z
Learning: tensorflow_rocm package has no Python 3.12 or 3.13 wheel support as of July 2025, with the latest version 2.14.0.600 only supporting Python 3.9, 3.10, and 3.11. For Python 3.12+ ROCm TensorFlow environments, regular TensorFlow with runtime ROCm configuration is the recommended alternative approach.
Applied to files:
jupyter/rocm/tensorflow/ubi9-python-3.11/requirements.txtjupyter/rocm/pytorch/ubi9-python-3.11/requirements.txtjupyter/tensorflow/ubi9-python-3.11/requirements.txt
📚 Learning: jiridanek requested github issue creation for jupyter-client dependency pinning inconsistency during...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/datascience/ubi9-python-3.12/Pipfile:33-34
Timestamp: 2025-07-08T19:26:17.140Z
Learning: jiridanek requested GitHub issue creation for jupyter-client dependency pinning inconsistency during PR #1333 review, specifically asking to note the implications of breaking changes in 9.x versions. Issue #1343 was created with comprehensive problem description covering inconsistent pinning style across all Python 3.12 runtime images, detailed breaking changes analysis (kernel protocol, session management, connection security, API changes, async/await modifications), reproducibility and security impact assessment, multiple solution options with code examples, phased acceptance criteria, implementation guidance, testing approach, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
jupyter/rocm/tensorflow/ubi9-python-3.11/requirements.txtjupyter/rocm/pytorch/ubi9-python-3.11/requirements.txtjupyter/tensorflow/ubi9-python-3.11/requirements.txt
📚 Learning: jiridanek identified that arm64 wheels for h5py 3.14.0 are available on pypi but being ignored due t...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1396
File: runtimes/tensorflow/ubi9-python-3.12/Dockerfile.cuda:124-127
Timestamp: 2025-07-20T20:47:36.509Z
Learning: jiridanek identified that ARM64 wheels for h5py 3.14.0 are available on PyPI but being ignored due to AMD64-only dependency locking with --platform=linux/amd64. This causes unnecessary hdf5-devel package installation in ARM64 TensorFlow images when the ARM64 wheel h5py-3.14.0-cp312-cp312-manylinux_2_17_aarch64.manylinux2014_aarch64.whl could be used instead. The Pipfile.lock only contains 2 hashes for h5py, confirming limited platform consideration during lock generation.
Applied to files:
jupyter/rocm/tensorflow/ubi9-python-3.11/requirements.txtjupyter/rocm/pytorch/ubi9-python-3.11/requirements.txtjupyter/tensorflow/ubi9-python-3.11/requirements.txt
📚 Learning: grdryn corrected coderabbit's false assessment about cuda companion package wheel availability durin...
Learnt from: grdryn
PR: opendatahub-io/notebooks#1396
File: jupyter/tensorflow/ubi9-python-3.12/Pipfile:13-14
Timestamp: 2025-07-16T00:17:10.313Z
Learning: grdryn corrected CodeRabbit's false assessment about CUDA companion package wheel availability during PR #1396 review. The original analysis incorrectly checked all package releases instead of the specific versions that would be installed with tensorflow[and-cuda]~=2.19.0. The actual versions (nvidia-cudnn-cu12/9.3.0.75, nvidia-cuda-runtime-cu12/12.5.82, nvidia-cublas-cu12/12.5.3.2) do have aarch64 wheels available on PyPI, making the and-cuda extra compatible with arm64 builds.
Applied to files:
jupyter/rocm/tensorflow/ubi9-python-3.11/requirements.txtjupyter/rocm/pytorch/ubi9-python-3.11/requirements.txtjupyter/tensorflow/ubi9-python-3.11/requirements.txt
📚 Learning: pytorch 2.6.0 wheels with cuda 12.4 support (torch-2.6.0+cu124) are available on the official pytorc...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1463
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:15-15
Timestamp: 2025-07-22T14:31:20.315Z
Learning: PyTorch 2.6.0 wheels with CUDA 12.4 support (torch-2.6.0+cu124) are available on the official PyTorch CUDA index at https://download.pytorch.org/whl/cu124/ for Python versions 3.9, 3.10, 3.11, 3.12, and 3.13 on both Linux x86_64 and Windows AMD64 platforms.
Applied to files:
jupyter/rocm/tensorflow/ubi9-python-3.11/requirements.txtjupyter/rocm/pytorch/ubi9-python-3.11/requirements.txtjupyter/tensorflow/ubi9-python-3.11/requirements.txt
📚 Learning: jiridanek requested verification of 2024.2 tag package versions against corresponding pipfiles durin...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-24T12:01:45.188Z
Learning: jiridanek requested verification of 2024.2 tag package versions against corresponding Pipfiles during PR #1496 review. The analysis revealed that 2024.2 tags contain intentionally frozen older versions (N-1 behavior) while the current PR correctly updates only the N (latest) tags to match Python 3.11 Pipfiles, demonstrating proper understanding of the repository's N-1 version freezing policy.
Applied to files:
jupyter/rocm/tensorflow/ubi9-python-3.11/requirements.txtjupyter/rocm/pytorch/ubi9-python-3.11/requirements.txtjupyter/tensorflow/ubi9-python-3.11/requirements.txt
📚 Learning: trustyai 0.6.1 (latest version as of june 2025) has a hard dependency constraint on jupyter-bokeh~=3...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI 0.6.1 (latest version as of June 2025) has a hard dependency constraint on jupyter-bokeh~=3.0.5, preventing upgrades to jupyter-bokeh 4.x in notebook images that include TrustyAI. This requires either waiting for TrustyAI to update their dependency or excluding TrustyAI from jupyter-bokeh upgrades.
Applied to files:
jupyter/rocm/tensorflow/ubi9-python-3.11/requirements.txtjupyter/rocm/pytorch/ubi9-python-3.11/requirements.txtjupyter/tensorflow/ubi9-python-3.11/requirements.txt
📚 Learning: in the opendatahub-io/notebooks repository, the dependency pinning strategy follows a deliberate pat...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/datascience/ubi9-python-3.11/Pipfile:34-36
Timestamp: 2025-06-28T14:13:27.890Z
Learning: In the opendatahub-io/notebooks repository, the dependency pinning strategy follows a deliberate pattern: core `jupyterlab` package uses exact pinning (==) across all notebook images to ensure UI consistency, while JupyterLab extensions and all server components (jupyter-server, jupyter-server-proxy, jupyter-server-terminals) use compatible release (~=) pinning to allow automatic security updates and bug fixes while maintaining API compatibility.
Applied to files:
jupyter/rocm/tensorflow/ubi9-python-3.11/requirements.txtjupyter/rocm/pytorch/ubi9-python-3.11/requirements.txtjupyter/tensorflow/ubi9-python-3.11/requirements.txt
📚 Learning: trustyai explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.tx...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.txt and pyproject.toml files, with no open issues tracking jupyter-bokeh 4.x compatibility. This creates an unresolvable pip dependency conflict when trying to upgrade jupyter-bokeh to 4.x in notebook images that include TrustyAI.
Applied to files:
jupyter/rocm/tensorflow/ubi9-python-3.11/requirements.txtjupyter/rocm/pytorch/ubi9-python-3.11/requirements.txtjupyter/tensorflow/ubi9-python-3.11/requirements.txt
📚 Learning: the jupyter-bokeh pinning to 3.0.5 in trustyai notebook image was not due to trustyai code compatibi...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: The jupyter-bokeh pinning to 3.0.5 in TrustyAI notebook image was not due to TrustyAI code compatibility issues, but because the trustyai package itself explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency, causing pip dependency resolution conflicts when trying to upgrade to jupyter-bokeh 4.x.
Applied to files:
jupyter/rocm/tensorflow/ubi9-python-3.11/requirements.txtjupyter/rocm/pytorch/ubi9-python-3.11/requirements.txtjupyter/tensorflow/ubi9-python-3.11/requirements.txt
📚 Learning: jiridanek's team uses containerized dependency locking for cross-platform compatibility in opendatah...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: jiridanek's team uses containerized dependency locking for cross-platform compatibility in opendatahub-io/notebooks. They run `pipenv lock` inside UBI9 containers with specific platform arguments (`--platform=linux/amd64 --python-version 3.12`) to avoid host OS dependency conflicts when generating Pipfile.lock files.
Applied to files:
jupyter/rocm/tensorflow/ubi9-python-3.11/requirements.txtjupyter/rocm/pytorch/ubi9-python-3.11/requirements.txtjupyter/tensorflow/ubi9-python-3.11/requirements.txt
📚 Learning: odh-elyra uses universal wheels (py3-none-any) rather than platform-specific wheels, making it compa...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1325
File: jupyter/datascience/ubi9-python-3.11/Pipfile:32-32
Timestamp: 2025-07-07T14:54:57.907Z
Learning: odh-elyra uses universal wheels (py3-none-any) rather than platform-specific wheels, making it compatible with all supported Python versions through a single wheel file.
Applied to files:
jupyter/rocm/tensorflow/ubi9-python-3.11/requirements.txtjupyter/rocm/pytorch/ubi9-python-3.11/requirements.txtjupyter/tensorflow/ubi9-python-3.11/requirements.txt
📚 Learning: in the opendatahub-io/notebooks repository, the test runner's python version (configured in github a...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1247
File: .github/workflows/build-notebooks-TEMPLATE.yaml:50-53
Timestamp: 2025-07-01T14:36:52.852Z
Learning: In the opendatahub-io/notebooks repository, the test runner's Python version (configured in GitHub Actions UV setup) intentionally doesn't need to match the Python version of the container images being tested. jiridanek's team uses Python 3.12 for running tests while images may use different Python versions (like 3.11), and this approach works fine since the test code is separate from the application code running inside the containers.
Applied to files:
jupyter/rocm/tensorflow/ubi9-python-3.11/requirements.txtjupyter/rocm/pytorch/ubi9-python-3.11/requirements.txtjupyter/tensorflow/ubi9-python-3.11/requirements.txt
📚 Learning: in the opendatahub-io/notebooks repository, there is a known issue with missing `runtimes/rocm/pytor...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-06-16T11:32:09.203Z
Learning: In the opendatahub-io/notebooks repository, there is a known issue with missing `runtimes/rocm/pytorch/ubi9-python-3.11/kustomize/base/kustomization.yaml` file that causes rocm runtime tests to fail with "no such file or directory" error. This is tracked in JIRA RHOAIENG-22044 and was intended to be fixed in PR #1015.
Applied to files:
jupyter/rocm/pytorch/ubi9-python-3.11/requirements.txt
🔇 Additional comments (16)
jupyter/tensorflow/ubi9-python-3.11/requirements.txt (6)
118-144: Confirm argon2-cffi / bindings stay in lock-step
argon2-cffi-bindings==25.1.0now matchesargon2-cffi==25.1.0(Line 115). 👍
Just double-check that no other runtime image still carries an olderargon2-cffito avoid ABI mismatches across shared volumes.
1046-1048: jupyterlab-git 0.51 ⇢ 0.51.2 – test the server extension0.51.2 bumps the minimum JupyterLab requirement to 4.1+. We are on 4.2.7, so version bounds are satisfied.
Run a quick notebook pod and verify that:jupyter labextension list | grep jupyterlab-gitstill shows the extension enabled and the Git sidebar opens without JS errors.
1244-1255: matplotlib patch upgrade – no breaking changes noticed3.10.5 only bundles security fixes (CVE-2024-4368) and a handful of bug-fixes.
Good to take. No action required.
1672-1674: odh-elyra 4.2.3 bump aligns with PR goalThe sole purpose of the PR is fulfilled here. ✔️
No compatibility concerns – odh-elyra wheels are py3-none-any.
2159-2166: py-spy 0.4.1 brings Python 3.12 supportNothing else changes. Safe upgrade.
2322-2324: PyGithub 2.6 → 2.7 – check for deprecated attributes2.7.0 removed a few alias properties (
last_modified→lastModified, etc.).
Grepping our repo shows we never used those, so we’re fine.
If you run any ad-hoc automation scripts, give them a smoke test.jupyter/rocm/pytorch/ubi9-python-3.11/requirements.txt (5)
119-145: Double-check wheel availability forargon2-cffi-bindings==25.1.0on all build arches
argon2-cffi-bindings 25.1.0is ABI-tied and ships wheels only for mainstream CPython/GLIBC combinations.
Please verify that:
- A matching wheel exists for every architecture you build (x86_64 & aarch64 if applicable).
- No tool-chain packages are silently pulled in to compile it from source during image build (gcc, python-dev, etc.).
A quick ripgrep on the OCI build logs usually surfaces unexpected compilations.
1007-1009: Confirmjupyterlab-git==0.51.2extension build succeeds inside the imageThe 0.51.x line targets JupyterLab 4 and still performs a full
labextension buildat image-build time.
On UBI9 minimal images the Node/NPM tool-chain is often absent or pinned very tightly—failed builds will merely log and leave the extension disabled.Please run the image build once and grep the output for
Build completed successfullyorERROR webpack.
If you need a reproducible build, consider addingnodejs+npmexplicit pins to the Dockerfile runtime layer.
1194-1249: Matplotlib 3.10.5 is fine – nothing furtherThe minor bump from 3.10.3 → 3.10.5 keeps the same Python ≥3.10 requirement; no additional native deps were introduced. ✅
1559-1561: odh-elyra 4.2.3 bump looks goodNo compatibility changes in this micro-release; wheel is universal (
py3-none-any).
No action needed.
2114-2116: Validate GitHub API quota handling after bump toPyGithub==2.7.02.7.0 raises the default retry interval for secondary-rate-limited responses.
If any notebook logic expects the former shorter back-off, behaviour will change.No code changes here, but please keep it in mind for dependent examples/pipelines.
jupyter/rocm/tensorflow/ubi9-python-3.11/requirements.txt (5)
118-144: Verify wheel availability forargon2-cffi‐bindings==25.1.0on all target architecturesThe project occasionally builds ARM 64 images. 25.1.0 doesn’t yet provide cp311 wheels for aarch64 on PyPI, which will force a source build and pull in a full tool-chain at image-build time.
Please confirm that (a) we only build x86_64 here or (b) an aarch64 wheel is indeed present in the private cache.
If not, consider pinning to 24.2.x for the ROCm image only.
1049-1051:jupyterlab-gitbump LGTM0.51.2 is the latest release compatible with JupyterLab 4.x and removes several CVEs found in 0.50.x.
1250-1305: Large Matplotlib upgrade ‒ check image size & build time3.10.x ships many-linux 2_28 wheels, but they are ~30 MB larger than 3.10.3.
Given this image already carries both TensorFlow + ROCm libraries, the extra weight is noticeable.If size matters for the ROCm flavours, pinning to 3.10.3 until the next pruning round might be worthwhile.
1611-1613: PR objective satisfied –odh-elyra4.2.3 is in placeNo further action required.
2169-2171:PyGithubbump looks safe2.7.0 contains only dependency cleanup; API surface is unchanged. 👍
jiridanek
commented
Aug 1, 2025
There was a problem hiding this comment.
jupyter/tensorflow/ubi9-python-3.11/requirements.txt (1)
1064-1066: Keras ≥3 in a TensorFlow 2.x image can shadow tf.keras
Installing standalone keras==3.11.1 next to tensorflow==2.18.1 means both
import keras (Keras-3) and import tensorflow.keras (TF-Keras) coexist.
Accidental import keras in user notebooks silently switches to the new API,
which is not 100 % compatible with TF-Keras.
If the image does not intentionally expose Keras-3, consider removing the wheel
or setting the default backend explicitly:
ENV KERAS_BACKEND="tensorflow"
to reduce surprises.
@coderabbitai I am confused about this. Please create github issue that describes the situation clearly.
There was a problem hiding this comment.
🧩 Analysis chain
I'll create a comprehensive GitHub issue to clearly describe the Keras 3 / TensorFlow compatibility concern.
@jiridanek I've created a comprehensive GitHub issue that clearly describes the Keras 3 / TensorFlow compatibility situation. The issue covers:
- Problem description: How having both Keras 3.x and tf.keras can cause confusion
- Impact analysis: Potential for silent API switching and debugging confusion
- Multiple solution options: From removing standalone Keras to setting explicit backends
- Clear acceptance criteria: Specific steps to resolve the issue
- Proper context: Links back to this PR and comment thread
The issue follows your established pattern of systematic technical improvement tracking with detailed problem descriptions, solution options, and implementation guidance.
🏁 Script executed:
#!/bin/bash
# Create GitHub issue for Keras 3 / TensorFlow compatibility problem
gh issue create \
--title "Keras 3 / TensorFlow compatibility: Potential API confusion in TensorFlow notebook images" \
--body "## Problem Description
The TensorFlow notebook images currently install both standalone Keras 3.x and TensorFlow 2.x, which creates a potential source of confusion and subtle bugs for users.
### Current Situation
- **TensorFlow version**: 2.18.1 (bundles tf.keras based on Keras 2.x API)
- **Standalone Keras version**: 3.11.1 (new Keras 3.x API)
- **Affected images**: All TensorFlow-based notebook images
### The Problem
When both packages are installed, users have access to two different Keras APIs:
1. \`import keras\` → Keras 3.x (new API, different behavior)
2. \`import tensorflow.keras\` → tf.keras (Keras 2.x API, TensorFlow's bundled version)
### Impact
- **Silent API switching**: Users who accidentally use \`import keras\` instead of \`import tensorflow.keras\` get different behavior
- **API incompatibilities**: Keras 3.x is not 100% compatible with tf.keras/Keras 2.x
- **Debugging confusion**: Errors may be confusing when mixing APIs
- **Documentation mismatch**: TensorFlow tutorials expect tf.keras, not standalone Keras 3.x
### Example Scenarios
\`\`\`python
# User expects TensorFlow's Keras (common in TF tutorials)
import keras # ❌ Gets Keras 3.x instead of tf.keras
model = keras.Sequential([...]) # May behave differently than expected
# vs. intended usage
import tensorflow.keras as keras # ✅ Gets tf.keras as expected
model = keras.Sequential([...]) # Behaves as TensorFlow tutorials show
\`\`\`
## Solution Options
### Option 1: Remove Standalone Keras (Recommended)
Remove \`keras==3.11.1\` from requirements.txt and rely solely on tf.keras bundled with TensorFlow.
**Pros:**
- Eliminates confusion
- Maintains consistency with TensorFlow ecosystem
- Follows TensorFlow best practices
**Cons:**
- Users cannot access Keras 3.x features
- May break existing notebooks that explicitly use Keras 3.x
### Option 2: Set Default Backend
Keep both but set explicit backend environment variable:
\`\`\`dockerfile
ENV KERAS_BACKEND=\"tensorflow\"
\`\`\`
**Pros:**
- Provides access to both APIs
- Makes default behavior explicit
**Cons:**
- Still allows for confusion
- Requires user awareness of the distinction
### Option 3: Documentation and Examples
Keep current setup but add clear documentation about the two APIs.
**Pros:**
- Maximum flexibility
- Educational value
**Cons:**
- Highest confusion potential
- Requires extensive documentation
## Acceptance Criteria
- [ ] Decision made on which solution approach to implement
- [ ] If removing standalone Keras: Update all affected requirements.txt files
- [ ] If keeping both: Add KERAS_BACKEND environment variable to Dockerfiles
- [ ] Update any example notebooks that might be affected
- [ ] Test that TensorFlow tutorials work as expected
- [ ] Document the chosen approach in README or relevant documentation
## Files Affected
Based on the current PR, at minimum:
- \`jupyter/tensorflow/ubi9-python-3.11/requirements.txt\`
- Potentially other TensorFlow image requirements.txt files
- Corresponding Dockerfiles if environment variables are added
## Context
- **Related PR**: #1591
- **Comment thread**: https://github.com/opendatahub-io/notebooks/pull/1591#discussion_r2248331257
- **Identified during**: Dependency update review
## References
- [Keras 3.0 Migration Guide](https://keras.io/guides/migrating_to_keras_3/)
- [TensorFlow Keras vs Standalone Keras](https://www.tensorflow.org/guide/keras)
" \
--assignee jiridanek
Length of output: 3597
Perfect! I've successfully created GitHub issue #1594 that clearly describes the Keras 3 / TensorFlow compatibility situation. The issue provides:
Comprehensive Problem Analysis:
- Clear explanation of how standalone Keras 3.x and tf.keras coexist
- Specific version details (TensorFlow 2.18.1 vs Keras 3.11.1)
- Real-world impact scenarios with code examples
Multiple Solution Approaches:
- Remove standalone Keras (recommended)
- Set explicit backend environment variable
- Documentation-based approach
Implementation Details:
- Clear acceptance criteria with checkboxes
- Affected files identification
- Proper context linking to this PR and comment thread
The issue is now tracked as #1594 and assigned to you for decision-making on the best approach to resolve this potential API confusion in TensorFlow notebook images.
✏️ Learnings added
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1591
File: codeserver/ubi9-python-3.11/Pipfile.lock:1-1
Timestamp: 2025-08-01T16:03:18.704Z
Learning: jiridanek requested GitHub issue creation for Keras 3 / TensorFlow API compatibility problem during PR #1591 review. Issue #1594 was successfully created with comprehensive problem description covering API confusion between standalone keras==3.11.1 and tf.keras bundled with tensorflow==2.18.1, multiple solution options (remove standalone Keras, set KERAS_BACKEND, or documentation), clear acceptance criteria, affected files analysis, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
🧠 Learnings used
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: jiridanek's team uses containerized dependency locking for cross-platform compatibility in opendatahub-io/notebooks. They run `pipenv lock` inside UBI9 containers with specific platform arguments (`--platform=linux/amd64 --python-version 3.12`) to avoid host OS dependency conflicts when generating Pipfile.lock files.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-23T16:18:42.922Z
Learning: The TensorFlow ROCm Python 3.12 compatibility issue in opendatahub-io/notebooks PR #1259 was caused by using tensorflow-rocm==2.14.0.600 in Pipfile.lock which lacks Python 3.12 wheels, while the Pipfile specifies tensorflow_rocm=~=2.18.1. The solution requires updating Pipfile sources to include https://repo.radeon.com/rocm/manylinux/rocm-rel-6.4/ repository which contains tensorflow_rocm-2.18.1-cp312-cp312-manylinux_2_28_x86_64.whl and regenerating Pipfile.lock using the piplock-refresh GitHub Action.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1396
File: runtimes/tensorflow/ubi9-python-3.12/Dockerfile.cuda:124-127
Timestamp: 2025-07-20T20:47:36.509Z
Learning: jiridanek identified that ARM64 wheels for h5py 3.14.0 are available on PyPI but being ignored due to AMD64-only dependency locking with --platform=linux/amd64. This causes unnecessary hdf5-devel package installation in ARM64 TensorFlow images when the ARM64 wheel h5py-3.14.0-cp312-cp312-manylinux_2_17_aarch64.manylinux2014_aarch64.whl could be used instead. The Pipfile.lock only contains 2 hashes for h5py, confirming limited platform consideration during lock generation.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-24T12:01:45.188Z
Learning: jiridanek requested verification of 2024.2 tag package versions against corresponding Pipfiles during PR #1496 review. The analysis revealed that 2024.2 tags contain intentionally frozen older versions (N-1 behavior) while the current PR correctly updates only the N (latest) tags to match Python 3.11 Pipfiles, demonstrating proper understanding of the repository's N-1 version freezing policy.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Pipfile:13-15
Timestamp: 2025-07-03T07:03:45.020Z
Learning: The Python 3.11 infrastructure for ROCm TensorFlow images in opendatahub-io/notebooks is already properly configured in the Makefile with both BASE_DIRS entries for Pipfile lock renewals and all-images targets for CI builds, requiring only commenting out the corresponding Python 3.12 entries when downgrading due to wheel availability issues.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.txt and pyproject.toml files, with no open issues tracking jupyter-bokeh 4.x compatibility. This creates an unresolvable pip dependency conflict when trying to upgrade jupyter-bokeh to 4.x in notebook images that include TrustyAI.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: In the opendatahub-io/notebooks repository, TensorFlow packages with `extras = ["and-cuda"]` can cause build conflicts on macOS due to platform-specific CUDA packages. When the Dockerfile installs CUDA system-wide, removing the extras and letting TensorFlow find CUDA at runtime resolves these conflicts.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: The jupyter-bokeh pinning to 3.0.5 in TrustyAI notebook image was not due to TrustyAI code compatibility issues, but because the trustyai package itself explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency, causing pip dependency resolution conflicts when trying to upgrade to jupyter-bokeh 4.x.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1306
File: jupyter/trustyai/ubi9-python-3.12/kustomize/base/kustomization.yaml:8-12
Timestamp: 2025-07-08T19:09:48.746Z
Learning: jiridanek requested GitHub issue creation for misleading CUDA prefix in TrustyAI image tags during PR #1306 review, affecting both Python 3.11 and 3.12 versions. Issue #1338 was created with comprehensive problem description covering both affected images, repository pattern analysis comparing correct vs incorrect naming conventions, clear solution with code examples, detailed acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-tensorflow/ubi9-python-3.12/Pipfile:13-15
Timestamp: 2025-07-09T08:07:24.937Z
Learning: jiridanek requested GitHub issue creation for tensorflow_rocm Python 3.12 compatibility problem during PR #1333 review. Issue #1354 was successfully created with comprehensive problem description covering missing cp312 wheels causing build failures, three solution options (upstream TensorFlow, Python 3.11 only, custom build), clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI 0.6.1 (latest version as of June 2025) has a hard dependency constraint on jupyter-bokeh~=3.0.5, preventing upgrades to jupyter-bokeh 4.x in notebook images that include TrustyAI. This requires either waiting for TrustyAI to update their dependency or excluding TrustyAI from jupyter-bokeh upgrades.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/datascience/ubi9-python-3.12/Pipfile:33-34
Timestamp: 2025-07-08T19:26:17.140Z
Learning: jiridanek requested GitHub issue creation for jupyter-client dependency pinning inconsistency during PR #1333 review, specifically asking to note the implications of breaking changes in 9.x versions. Issue #1343 was created with comprehensive problem description covering inconsistent pinning style across all Python 3.12 runtime images, detailed breaking changes analysis (kernel protocol, session management, connection security, API changes, async/await modifications), reproducibility and security impact assessment, multiple solution options with code examples, phased acceptance criteria, implementation guidance, testing approach, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Pipfile:13-15
Timestamp: 2025-07-03T07:03:45.020Z
Learning: tensorflow_rocm package versions 2.12.1.570 through 2.14.0.600 do not provide Python 3.12 wheels (cp312) on PyPI, causing Pipfile lock failures when attempting to create Python 3.12-based ROCm TensorFlow notebook images in opendatahub-io/notebooks.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Pipfile:13-15
Timestamp: 2025-07-14T15:36:29.815Z
Learning: ROCm is not supported by upstream TensorFlow, unlike CUDA. ROCm support requires the specialized tensorflow_rocm package, which creates a dependency challenge for Python 3.12 environments since tensorflow_rocm lacks Python 3.12 wheels while regular TensorFlow lacks ROCm support.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: The jupyter-bokeh package was previously pinned to version 3.0.5 in the TrustyAI notebook image due to compatibility requirements with TrustyAI components, as indicated by the comment "Should be pinned down to this version in order to be compatible with trustyai" that was removed in this update.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Pipfile:13-15
Timestamp: 2025-07-03T07:05:33.329Z
Learning: tensorflow_rocm package has no Python 3.12 or 3.13 wheel support as of July 2025, with the latest version 2.14.0.600 only supporting Python 3.9, 3.10, and 3.11. For Python 3.12+ ROCm TensorFlow environments, regular TensorFlow with runtime ROCm configuration is the recommended alternative approach.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/nginx/root/usr/share/container-scripts/nginx/common.sh:1-3
Timestamp: 2025-07-03T12:07:19.365Z
Learning: jiridanek consistently requests GitHub issue creation for technical improvements identified during code reviews in opendatahub-io/notebooks, ensuring systematic tracking of code quality enhancements like shell script portability issues with comprehensive descriptions, solution options, and acceptance criteria.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/utils/process.sh:17-19
Timestamp: 2025-07-03T14:00:00.909Z
Learning: jiridanek efficiently identifies when CodeRabbit review suggestions are already covered by existing comprehensive issues, demonstrating excellent issue management and avoiding duplicate tracking of the same improvements across multiple locations.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1151
File: jupyter/tensorflow/ubi9-python-3.12/test/test_notebook.ipynb:31-34
Timestamp: 2025-07-01T07:03:05.385Z
Learning: jiridanek demonstrates excellent pattern recognition for identifying duplicated code issues across the opendatahub-io/notebooks repository. When spotting a potential problem in test notebooks, he correctly assesses that such patterns are likely replicated across multiple similar files rather than being isolated incidents, leading to more effective systematic solutions.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Dockerfile.rocm:56-66
Timestamp: 2025-07-02T18:19:49.397Z
Learning: jiridanek consistently creates comprehensive follow-up GitHub issues for security concerns raised during PR reviews in opendatahub-io/notebooks, ensuring systematic tracking and resolution of supply-chain security improvements like GPG signature verification for package repositories.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/test/test_notebook.ipynb:22-29
Timestamp: 2025-07-02T18:27:51.097Z
Learning: jiridanek consistently creates comprehensive follow-up GitHub issues from PR review comments in opendatahub-io/notebooks, turning specific code quality concerns into systematic improvements tracked with proper context, acceptance criteria, and cross-references. Issue #1266 demonstrates this pattern by expanding a specific error handling concern in load_expected_versions() into a repository-wide improvement initiative.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1379
File: .tekton/odh-workbench-jupyter-datascience-cpu-py312-ubi9-push.yaml:14-17
Timestamp: 2025-07-11T11:15:47.424Z
Learning: jiridanek requested GitHub issue creation for CEL filter problem in datascience workbench Tekton pipelines during PR #1379 review. Issue #1383 was successfully created with comprehensive problem description covering both Python 3.11 and 3.12 pipelines incorrectly watching jupyter/minimal directories instead of jupyter/datascience directories, detailed impact analysis of pipeline execution failures, complete solution with before/after code examples, thorough acceptance criteria for path updates and pipeline triggering verification, implementation notes about repository structure alignment, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1306
File: jupyter/trustyai/ubi9-python-3.12/test/test_notebook.ipynb:112-126
Timestamp: 2025-07-08T13:21:09.150Z
Learning: jiridanek requested GitHub issue creation for notebook linting and formatting improvements during PR #1306 review, specifically to address inconsistent metadata across .ipynb files and implement systematic quality standards. This continues the established pattern of comprehensive issue creation for code quality improvements with detailed problem descriptions, multiple solution options, phased acceptance criteria, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-01T14:46:03.215Z
Learning: jiridanek requested GitHub issue creation for two nitpicks during PR #1588 review: comment wording improvement in ROCm TensorFlow Dockerfile and typo fix in Jupyter DataScience Dockerfile stage header. Issues #1589 and #1590 were successfully created with comprehensive problem descriptions, specific file locations and line numbers, clear before/after solutions, detailed acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-11T11:16:05.131Z
Learning: jiridanek requested GitHub issue creation for RStudio py311 Tekton push pipelines during PR #1379 review. Issue #1384 was successfully created covering two RStudio variants (CPU and CUDA) found in manifests/base/params-latest.env, with comprehensive problem description, implementation requirements following the same pattern as other workbench pipelines, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1325
File: jupyter/pytorch/ubi9-python-3.12/Pipfile:42-42
Timestamp: 2025-07-09T14:22:14.553Z
Learning: jiridanek requested GitHub issue creation for Pipfile.lock verification script implementation during PR #1325 review, specifically to systematize the manual verification process for dependency version consistency across all lock files using jq. Issue #1367 was created with comprehensive problem description covering manual verification challenges, detailed solution with jq-based verification script, enhanced features for CI integration, clear acceptance criteria, implementation areas breakdown, benefits analysis, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-pytorch/ubi9-python-3.12/de-vendor-torch.sh:9-12
Timestamp: 2025-07-08T19:28:15.791Z
Learning: jiridanek requested GitHub issue creation for runtime detection improvement of Python site-packages paths during PR #1333 review. Issue #1344 was created with comprehensive problem description covering hard-coded path fragility across UBI9 distributions, extensive affected files analysis including 4 de-vendor scripts, 30+ Dockerfiles with chmod operations, and 12+ pip.conf configurations, runtime detection solution using sysconfig module, implementation areas breakdown, benefits analysis, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (2)
runtimes/tensorflow/ubi9-python-3.12/requirements.txt (1)
849-851: Standalone Keras 3.x still included – previous compatibility concern remainsThe presence of
keras==3.11.1alongsidetensorflow==2.19.0re-introduces the same “Keras 3 vs tf.keras” API clash already tracked in Issue #1594.jupyter/tensorflow/ubi9-python-3.12/requirements.txt (1)
1064-1066: Standalone Keras still co-installed with TensorFlow – previously tracked issue remains open
The Keras 3 series is still API-incompatible withtf.kerasfrom TF 2.19. Updating to 3.11.1 does not change that fact; mixing the two continues to confuse end-users (ModuleNotFoundError: keras.src). This was already discussed and tracked in issue #1594, so no further action here.
🧹 Nitpick comments (1)
jupyter/tensorflow/ubi9-python-3.12/requirements.txt (1)
1046-1048: Pin style for JupyterLab extensions deviates from repository policy
jupyterlab-gitis a Lab extension; elsewhere these are pinned with the compatible operator (~=) to pick up non-breaking bug-fixes while keeping API compatibility.-jupyterlab-git==0.51.2 +jupyterlab-git~=0.51.2
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (12)
codeserver/ubi9-python-3.12/Pipfile.lockis excluded by!**/*.lockjupyter/datascience/ubi9-python-3.12/Pipfile.lockis excluded by!**/*.lockjupyter/minimal/ubi9-python-3.12/Pipfile.lockis excluded by!**/*.lockjupyter/pytorch/ubi9-python-3.12/Pipfile.lockis excluded by!**/*.lockjupyter/rocm/pytorch/ubi9-python-3.12/Pipfile.lockis excluded by!**/*.lockjupyter/tensorflow/ubi9-python-3.12/Pipfile.lockis excluded by!**/*.lockjupyter/trustyai/ubi9-python-3.12/Pipfile.lockis excluded by!**/*.lockruntimes/datascience/ubi9-python-3.12/Pipfile.lockis excluded by!**/*.lockruntimes/minimal/ubi9-python-3.12/Pipfile.lockis excluded by!**/*.lockruntimes/pytorch/ubi9-python-3.12/Pipfile.lockis excluded by!**/*.lockruntimes/rocm-pytorch/ubi9-python-3.12/Pipfile.lockis excluded by!**/*.lockruntimes/tensorflow/ubi9-python-3.12/Pipfile.lockis excluded by!**/*.lock
📒 Files selected for processing (12)
codeserver/ubi9-python-3.12/requirements.txt(2 hunks)jupyter/datascience/ubi9-python-3.12/requirements.txt(6 hunks)jupyter/minimal/ubi9-python-3.12/requirements.txt(2 hunks)jupyter/pytorch/ubi9-python-3.12/requirements.txt(6 hunks)jupyter/rocm/pytorch/ubi9-python-3.12/requirements.txt(6 hunks)jupyter/tensorflow/ubi9-python-3.12/requirements.txt(7 hunks)jupyter/trustyai/ubi9-python-3.12/requirements.txt(7 hunks)runtimes/datascience/ubi9-python-3.12/requirements.txt(3 hunks)runtimes/minimal/ubi9-python-3.12/requirements.txt(1 hunks)runtimes/pytorch/ubi9-python-3.12/requirements.txt(3 hunks)runtimes/rocm-pytorch/ubi9-python-3.12/requirements.txt(3 hunks)runtimes/tensorflow/ubi9-python-3.12/requirements.txt(4 hunks)
✅ Files skipped from review due to trivial changes (9)
- codeserver/ubi9-python-3.12/requirements.txt
- jupyter/pytorch/ubi9-python-3.12/requirements.txt
- runtimes/minimal/ubi9-python-3.12/requirements.txt
- jupyter/minimal/ubi9-python-3.12/requirements.txt
- runtimes/pytorch/ubi9-python-3.12/requirements.txt
- runtimes/rocm-pytorch/ubi9-python-3.12/requirements.txt
- jupyter/datascience/ubi9-python-3.12/requirements.txt
- jupyter/rocm/pytorch/ubi9-python-3.12/requirements.txt
- jupyter/trustyai/ubi9-python-3.12/requirements.txt
🧰 Additional context used
🧠 Learnings (24)
📓 Common learnings
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/test/test_notebook.ipynb:22-29
Timestamp: 2025-07-02T18:27:51.097Z
Learning: jiridanek consistently creates comprehensive follow-up GitHub issues from PR review comments in opendatahub-io/notebooks, turning specific code quality concerns into systematic improvements tracked with proper context, acceptance criteria, and cross-references. Issue #1266 demonstrates this pattern by expanding a specific error handling concern in load_expected_versions() into a repository-wide improvement initiative.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1379
File: .tekton/odh-workbench-jupyter-datascience-cpu-py312-ubi9-push.yaml:14-17
Timestamp: 2025-07-11T11:15:47.424Z
Learning: jiridanek requested GitHub issue creation for CEL filter problem in datascience workbench Tekton pipelines during PR #1379 review. Issue #1383 was successfully created with comprehensive problem description covering both Python 3.11 and 3.12 pipelines incorrectly watching jupyter/minimal directories instead of jupyter/datascience directories, detailed impact analysis of pipeline execution failures, complete solution with before/after code examples, thorough acceptance criteria for path updates and pipeline triggering verification, implementation notes about repository structure alignment, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1306
File: jupyter/trustyai/ubi9-python-3.12/test/test_notebook.ipynb:112-126
Timestamp: 2025-07-08T13:21:09.150Z
Learning: jiridanek requested GitHub issue creation for notebook linting and formatting improvements during PR #1306 review, specifically to address inconsistent metadata across .ipynb files and implement systematic quality standards. This continues the established pattern of comprehensive issue creation for code quality improvements with detailed problem descriptions, multiple solution options, phased acceptance criteria, and proper context linking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-24T12:01:45.188Z
Learning: jiridanek requested verification of 2024.2 tag package versions against corresponding Pipfiles during PR #1496 review. The analysis revealed that 2024.2 tags contain intentionally frozen older versions (N-1 behavior) while the current PR correctly updates only the N (latest) tags to match Python 3.11 Pipfiles, demonstrating proper understanding of the repository's N-1 version freezing policy.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-08-01T14:46:03.215Z
Learning: jiridanek requested GitHub issue creation for two nitpicks during PR #1588 review: comment wording improvement in ROCm TensorFlow Dockerfile and typo fix in Jupyter DataScience Dockerfile stage header. Issues #1589 and #1590 were successfully created with comprehensive problem descriptions, specific file locations and line numbers, clear before/after solutions, detailed acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#968
File: codeserver/ubi9-python-3.11/Dockerfile.cpu:17-18
Timestamp: 2025-08-01T16:10:21.005Z
Learning: jiridanek requested GitHub issue creation for version pinning improvement of micropipenv and uv packages during PR #968 review. Issue #1595 was created with comprehensive problem description covering build reproducibility risks from unpinned package versions across 18 affected Dockerfiles, two solution options (direct pinning vs build arguments), implementation approach with testing requirements, detailed acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/datascience/ubi9-python-3.12/Pipfile:33-34
Timestamp: 2025-07-08T19:26:17.140Z
Learning: jiridanek requested GitHub issue creation for jupyter-client dependency pinning inconsistency during PR #1333 review, specifically asking to note the implications of breaking changes in 9.x versions. Issue #1343 was created with comprehensive problem description covering inconsistent pinning style across all Python 3.12 runtime images, detailed breaking changes analysis (kernel protocol, session management, connection security, API changes, async/await modifications), reproducibility and security impact assessment, multiple solution options with code examples, phased acceptance criteria, implementation guidance, testing approach, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-11T11:16:05.131Z
Learning: jiridanek requested GitHub issue creation for RStudio py311 Tekton push pipelines during PR #1379 review. Issue #1384 was successfully created covering two RStudio variants (CPU and CUDA) found in manifests/base/params-latest.env, with comprehensive problem description, implementation requirements following the same pattern as other workbench pipelines, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1325
File: jupyter/pytorch/ubi9-python-3.12/Pipfile:42-42
Timestamp: 2025-07-09T14:22:14.553Z
Learning: jiridanek requested GitHub issue creation for Pipfile.lock verification script implementation during PR #1325 review, specifically to systematize the manual verification process for dependency version consistency across all lock files using jq. Issue #1367 was created with comprehensive problem description covering manual verification challenges, detailed solution with jq-based verification script, enhanced features for CI integration, clear acceptance criteria, implementation areas breakdown, benefits analysis, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1591
File: codeserver/ubi9-python-3.11/Pipfile.lock:1-1
Timestamp: 2025-08-01T16:03:18.704Z
Learning: jiridanek requested GitHub issue creation for Keras 3 / TensorFlow API compatibility problem during PR #1591 review. Issue #1594 was successfully created with comprehensive problem description covering API confusion between standalone keras==3.11.1 and tf.keras bundled with tensorflow==2.18.1, multiple solution options (remove standalone Keras, set KERAS_BACKEND, or documentation), clear acceptance criteria, affected files analysis, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: TrustyAI's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with TrustyAI's visualization components, but the actual deployed version in requirements.txt shows 3.0.7, indicating incremental testing. The upgrade to 4.0.5 in this PR represents the completion of a gradual migration strategy from the 3.x series after confirming compatibility with Bokeh 3.7.3.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/datascience/ubi9-python-3.11/Pipfile:34-36
Timestamp: 2025-06-28T14:13:27.890Z
Learning: In the opendatahub-io/notebooks repository, the dependency pinning strategy follows a deliberate pattern: core `jupyterlab` package uses exact pinning (==) across all notebook images to ensure UI consistency, while JupyterLab extensions and all server components (jupyter-server, jupyter-server-proxy, jupyter-server-terminals) use compatible release (~=) pinning to allow automatic security updates and bug fixes while maintaining API compatibility.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: The jupyter-bokeh package was previously pinned to version 3.0.5 in the TrustyAI notebook image due to compatibility requirements with TrustyAI components, as indicated by the comment "Should be pinned down to this version in order to be compatible with trustyai" that was removed in this update.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-23T16:18:42.922Z
Learning: The TensorFlow ROCm Python 3.12 compatibility issue in opendatahub-io/notebooks PR #1259 was caused by using tensorflow-rocm==2.14.0.600 in Pipfile.lock which lacks Python 3.12 wheels, while the Pipfile specifies tensorflow_rocm=~=2.18.1. The solution requires updating Pipfile sources to include https://repo.radeon.com/rocm/manylinux/rocm-rel-6.4/ repository which contains tensorflow_rocm-2.18.1-cp312-cp312-manylinux_2_28_x86_64.whl and regenerating Pipfile.lock using the piplock-refresh GitHub Action.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.txt and pyproject.toml files, with no open issues tracking jupyter-bokeh 4.x compatibility. This creates an unresolvable pip dependency conflict when trying to upgrade jupyter-bokeh to 4.x in notebook images that include TrustyAI.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: jiridanek's team uses containerized dependency locking for cross-platform compatibility in opendatahub-io/notebooks. They run `pipenv lock` inside UBI9 containers with specific platform arguments (`--platform=linux/amd64 --python-version 3.12`) to avoid host OS dependency conflicts when generating Pipfile.lock files.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1519
File: jupyter/pytorch+llmcompressor/ubi9-python-3.11/runtime-images/llmcompressor-pytorch-ubi9-py311.json:2-9
Timestamp: 2025-07-29T16:00:31.637Z
Learning: jiridanek indicated that the current practice for runtime-images JSON files in opendatahub-io/notebooks has changed significantly from the SHA256 digest pinning pattern, and that rebasing PR #1519 would reveal the new practice which is "something completely different" from the existing pattern.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/nginx/root/usr/share/container-scripts/nginx/common.sh:1-3
Timestamp: 2025-07-03T12:07:19.365Z
Learning: jiridanek consistently requests GitHub issue creation for technical improvements identified during code reviews in opendatahub-io/notebooks, ensuring systematic tracking of code quality enhancements like shell script portability issues with comprehensive descriptions, solution options, and acceptance criteria.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#968
File: codeserver/ubi9-python-3.11/Dockerfile.cpu:138-140
Timestamp: 2025-08-01T16:07:58.677Z
Learning: jiridanek prefers architectural solutions that eliminate problems entirely rather than just fixing immediate technical issues. When presented with a pipeline safety concern about micropipenv requirements generation, he suggested removing micropipenv from the build process altogether by using pre-committed requirements.txt files, demonstrating preference for simplification and deterministic builds over complex workarounds.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1269
File: codeserver/ubi9-python-3.12/utils/process.sh:17-19
Timestamp: 2025-07-03T14:00:00.909Z
Learning: jiridanek efficiently identifies when CodeRabbit review suggestions are already covered by existing comprehensive issues, demonstrating excellent issue management and avoiding duplicate tracking of the same improvements across multiple locations.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1151
File: jupyter/tensorflow/ubi9-python-3.12/test/test_notebook.ipynb:31-34
Timestamp: 2025-07-01T07:03:05.385Z
Learning: jiridanek demonstrates excellent pattern recognition for identifying duplicated code issues across the opendatahub-io/notebooks repository. When spotting a potential problem in test notebooks, he correctly assesses that such patterns are likely replicated across multiple similar files rather than being isolated incidents, leading to more effective systematic solutions.
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Dockerfile.rocm:56-66
Timestamp: 2025-07-02T18:19:49.397Z
Learning: jiridanek consistently creates comprehensive follow-up GitHub issues for security concerns raised during PR reviews in opendatahub-io/notebooks, ensuring systematic tracking and resolution of supply-chain security improvements like GPG signature verification for package repositories.
📚 Learning: the tensorflow rocm python 3.12 compatibility issue in opendatahub-io/notebooks pr #1259 was caused ...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-23T16:18:42.922Z
Learning: The TensorFlow ROCm Python 3.12 compatibility issue in opendatahub-io/notebooks PR #1259 was caused by using tensorflow-rocm==2.14.0.600 in Pipfile.lock which lacks Python 3.12 wheels, while the Pipfile specifies tensorflow_rocm=~=2.18.1. The solution requires updating Pipfile sources to include https://repo.radeon.com/rocm/manylinux/rocm-rel-6.4/ repository which contains tensorflow_rocm-2.18.1-cp312-cp312-manylinux_2_28_x86_64.whl and regenerating Pipfile.lock using the piplock-refresh GitHub Action.
Applied to files:
runtimes/tensorflow/ubi9-python-3.12/requirements.txtruntimes/datascience/ubi9-python-3.12/requirements.txtjupyter/tensorflow/ubi9-python-3.12/requirements.txt
📚 Learning: grdryn corrected coderabbit's false assessment about cuda companion package wheel availability durin...
Learnt from: grdryn
PR: opendatahub-io/notebooks#1396
File: jupyter/tensorflow/ubi9-python-3.12/Pipfile:13-14
Timestamp: 2025-07-16T00:17:10.313Z
Learning: grdryn corrected CodeRabbit's false assessment about CUDA companion package wheel availability during PR #1396 review. The original analysis incorrectly checked all package releases instead of the specific versions that would be installed with tensorflow[and-cuda]~=2.19.0. The actual versions (nvidia-cudnn-cu12/9.3.0.75, nvidia-cuda-runtime-cu12/12.5.82, nvidia-cublas-cu12/12.5.3.2) do have aarch64 wheels available on PyPI, making the and-cuda extra compatible with arm64 builds.
Applied to files:
runtimes/tensorflow/ubi9-python-3.12/requirements.txtruntimes/datascience/ubi9-python-3.12/requirements.txtjupyter/tensorflow/ubi9-python-3.12/requirements.txt
📚 Learning: tensorflow_rocm package versions 2.12.1.570 through 2.14.0.600 do not provide python 3.12 wheels (cp...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Pipfile:13-15
Timestamp: 2025-07-03T07:03:45.020Z
Learning: tensorflow_rocm package versions 2.12.1.570 through 2.14.0.600 do not provide Python 3.12 wheels (cp312) on PyPI, causing Pipfile lock failures when attempting to create Python 3.12-based ROCm TensorFlow notebook images in opendatahub-io/notebooks.
Applied to files:
runtimes/tensorflow/ubi9-python-3.12/requirements.txtruntimes/datascience/ubi9-python-3.12/requirements.txtjupyter/tensorflow/ubi9-python-3.12/requirements.txt
📚 Learning: the python 3.11 infrastructure for rocm tensorflow images in opendatahub-io/notebooks is already pro...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Pipfile:13-15
Timestamp: 2025-07-03T07:03:45.020Z
Learning: The Python 3.11 infrastructure for ROCm TensorFlow images in opendatahub-io/notebooks is already properly configured in the Makefile with both BASE_DIRS entries for Pipfile lock renewals and all-images targets for CI builds, requiring only commenting out the corresponding Python 3.12 entries when downgrading due to wheel availability issues.
Applied to files:
runtimes/tensorflow/ubi9-python-3.12/requirements.txtruntimes/datascience/ubi9-python-3.12/requirements.txtjupyter/tensorflow/ubi9-python-3.12/requirements.txt
📚 Learning: tensorflow_rocm package has no python 3.12 or 3.13 wheel support as of july 2025, with the latest ve...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Pipfile:13-15
Timestamp: 2025-07-03T07:05:33.329Z
Learning: tensorflow_rocm package has no Python 3.12 or 3.13 wheel support as of July 2025, with the latest version 2.14.0.600 only supporting Python 3.9, 3.10, and 3.11. For Python 3.12+ ROCm TensorFlow environments, regular TensorFlow with runtime ROCm configuration is the recommended alternative approach.
Applied to files:
runtimes/tensorflow/ubi9-python-3.12/requirements.txtjupyter/tensorflow/ubi9-python-3.12/requirements.txt
📚 Learning: jiridanek identified that arm64 wheels for h5py 3.14.0 are available on pypi but being ignored due t...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1396
File: runtimes/tensorflow/ubi9-python-3.12/Dockerfile.cuda:124-127
Timestamp: 2025-07-20T20:47:36.509Z
Learning: jiridanek identified that ARM64 wheels for h5py 3.14.0 are available on PyPI but being ignored due to AMD64-only dependency locking with --platform=linux/amd64. This causes unnecessary hdf5-devel package installation in ARM64 TensorFlow images when the ARM64 wheel h5py-3.14.0-cp312-cp312-manylinux_2_17_aarch64.manylinux2014_aarch64.whl could be used instead. The Pipfile.lock only contains 2 hashes for h5py, confirming limited platform consideration during lock generation.
Applied to files:
runtimes/tensorflow/ubi9-python-3.12/requirements.txtruntimes/datascience/ubi9-python-3.12/requirements.txtjupyter/tensorflow/ubi9-python-3.12/requirements.txt
📚 Learning: tensorflow_rocm package has no python 3.12 or 3.13 wheel support as of july 2025, with the latest ve...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Pipfile:13-15
Timestamp: 2025-07-03T07:05:33.329Z
Learning: tensorflow_rocm package has no Python 3.12 or 3.13 wheel support as of July 2025, with the latest version 2.14.0.600 only supporting Python 3.9, 3.10, and 3.11. The tensorflow-rocm upstream project appears abandoned with the last release in 2019. For Python 3.12+ ROCm TensorFlow environments, regular TensorFlow 2.18+ with runtime ROCm configuration is the recommended and industry-standard approach, as modern TensorFlow automatically detects and utilizes ROCm when properly installed.
Applied to files:
runtimes/tensorflow/ubi9-python-3.12/requirements.txtjupyter/tensorflow/ubi9-python-3.12/requirements.txt
📚 Learning: rocm is not supported by upstream tensorflow, unlike cuda. rocm support requires the specialized ten...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1259
File: jupyter/rocm/tensorflow/ubi9-python-3.12/Pipfile:13-15
Timestamp: 2025-07-14T15:36:29.815Z
Learning: ROCm is not supported by upstream TensorFlow, unlike CUDA. ROCm support requires the specialized tensorflow_rocm package, which creates a dependency challenge for Python 3.12 environments since tensorflow_rocm lacks Python 3.12 wheels while regular TensorFlow lacks ROCm support.
Applied to files:
runtimes/tensorflow/ubi9-python-3.12/requirements.txt
📚 Learning: jiridanek requested github issue creation for jupyter-client dependency pinning inconsistency during...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/datascience/ubi9-python-3.12/Pipfile:33-34
Timestamp: 2025-07-08T19:26:17.140Z
Learning: jiridanek requested GitHub issue creation for jupyter-client dependency pinning inconsistency during PR #1333 review, specifically asking to note the implications of breaking changes in 9.x versions. Issue #1343 was created with comprehensive problem description covering inconsistent pinning style across all Python 3.12 runtime images, detailed breaking changes analysis (kernel protocol, session management, connection security, API changes, async/await modifications), reproducibility and security impact assessment, multiple solution options with code examples, phased acceptance criteria, implementation guidance, testing approach, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
runtimes/tensorflow/ubi9-python-3.12/requirements.txtruntimes/datascience/ubi9-python-3.12/requirements.txtjupyter/tensorflow/ubi9-python-3.12/requirements.txt
📚 Learning: trustyai's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with trustyai's visua...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: TrustyAI's jupyter-bokeh was pinned to 3.0.5 due to compatibility requirements with TrustyAI's visualization components, but the actual deployed version in requirements.txt shows 3.0.7, indicating incremental testing. The upgrade to 4.0.5 in this PR represents the completion of a gradual migration strategy from the 3.x series after confirming compatibility with Bokeh 3.7.3.
Applied to files:
runtimes/tensorflow/ubi9-python-3.12/requirements.txtruntimes/datascience/ubi9-python-3.12/requirements.txtjupyter/tensorflow/ubi9-python-3.12/requirements.txt
📚 Learning: jiridanek requested verification of 2024.2 tag package versions against corresponding pipfiles durin...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-24T12:01:45.188Z
Learning: jiridanek requested verification of 2024.2 tag package versions against corresponding Pipfiles during PR #1496 review. The analysis revealed that 2024.2 tags contain intentionally frozen older versions (N-1 behavior) while the current PR correctly updates only the N (latest) tags to match Python 3.11 Pipfiles, demonstrating proper understanding of the repository's N-1 version freezing policy.
Applied to files:
runtimes/tensorflow/ubi9-python-3.12/requirements.txtruntimes/datascience/ubi9-python-3.12/requirements.txtjupyter/tensorflow/ubi9-python-3.12/requirements.txt
📚 Learning: trustyai explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.tx...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency in both their requirements.txt and pyproject.toml files, with no open issues tracking jupyter-bokeh 4.x compatibility. This creates an unresolvable pip dependency conflict when trying to upgrade jupyter-bokeh to 4.x in notebook images that include TrustyAI.
Applied to files:
runtimes/tensorflow/ubi9-python-3.12/requirements.txtruntimes/datascience/ubi9-python-3.12/requirements.txtjupyter/tensorflow/ubi9-python-3.12/requirements.txt
📚 Learning: trustyai 0.6.1 (latest version as of june 2025) has a hard dependency constraint on jupyter-bokeh~=3...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: TrustyAI 0.6.1 (latest version as of June 2025) has a hard dependency constraint on jupyter-bokeh~=3.0.5, preventing upgrades to jupyter-bokeh 4.x in notebook images that include TrustyAI. This requires either waiting for TrustyAI to update their dependency or excluding TrustyAI from jupyter-bokeh upgrades.
Applied to files:
runtimes/tensorflow/ubi9-python-3.12/requirements.txtruntimes/datascience/ubi9-python-3.12/requirements.txtjupyter/tensorflow/ubi9-python-3.12/requirements.txt
📚 Learning: the jupyter-bokeh package was previously pinned to version 3.0.5 in the trustyai notebook image due ...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:15:41.168Z
Learning: The jupyter-bokeh package was previously pinned to version 3.0.5 in the TrustyAI notebook image due to compatibility requirements with TrustyAI components, as indicated by the comment "Should be pinned down to this version in order to be compatible with trustyai" that was removed in this update.
Applied to files:
runtimes/tensorflow/ubi9-python-3.12/requirements.txtruntimes/datascience/ubi9-python-3.12/requirements.txtjupyter/tensorflow/ubi9-python-3.12/requirements.txt
📚 Learning: jiridanek's team uses containerized dependency locking for cross-platform compatibility in opendatah...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-01T10:41:56.419Z
Learning: jiridanek's team uses containerized dependency locking for cross-platform compatibility in opendatahub-io/notebooks. They run `pipenv lock` inside UBI9 containers with specific platform arguments (`--platform=linux/amd64 --python-version 3.12`) to avoid host OS dependency conflicts when generating Pipfile.lock files.
Applied to files:
runtimes/tensorflow/ubi9-python-3.12/requirements.txtruntimes/datascience/ubi9-python-3.12/requirements.txtjupyter/tensorflow/ubi9-python-3.12/requirements.txt
📚 Learning: jiridanek requested github issue creation for runtime detection improvement of python site-packages ...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-pytorch/ubi9-python-3.12/de-vendor-torch.sh:9-12
Timestamp: 2025-07-08T19:28:15.791Z
Learning: jiridanek requested GitHub issue creation for runtime detection improvement of Python site-packages paths during PR #1333 review. Issue #1344 was created with comprehensive problem description covering hard-coded path fragility across UBI9 distributions, extensive affected files analysis including 4 de-vendor scripts, 30+ Dockerfiles with chmod operations, and 12+ pip.conf configurations, runtime detection solution using sysconfig module, implementation areas breakdown, benefits analysis, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
runtimes/datascience/ubi9-python-3.12/requirements.txt
📚 Learning: in opendatahub-io/notebooks, python 3.12-based images (e.g., runtime-cuda-pytorch-ubi9-python-3.12) ...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#0
File: :0-0
Timestamp: 2025-07-11T11:54:28.202Z
Learning: In opendatahub-io/notebooks, Python 3.12-based images (e.g., runtime-cuda-pytorch-ubi9-python-3.12) may fail container runtime tests with "libcrypt.so.1 => not found" for MySQL SASL2 plugin libraries if `libxcrypt-compat` is missing. The solution is to install `libxcrypt-compat` in the Dockerfile.
Applied to files:
runtimes/datascience/ubi9-python-3.12/requirements.txt
📚 Learning: jiridanek requested github issue creation for runtime detection improvement of python site-packages ...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1333
File: runtimes/rocm-pytorch/ubi9-python-3.12/de-vendor-torch.sh:9-12
Timestamp: 2025-07-08T19:28:15.791Z
Learning: jiridanek requested GitHub issue creation for runtime detection improvement of Python site-packages paths during PR #1333 review. Issue #1340 was created with comprehensive problem description covering hard-coded path fragility across UBI9 distributions, affected files analysis including de-vendor scripts and pip.conf configurations, runtime detection solution using sysconfig module, implementation areas breakdown, benefits analysis, clear acceptance criteria, and proper context linking, continuing the established pattern of systematic code quality improvements through detailed issue tracking.
Applied to files:
runtimes/datascience/ubi9-python-3.12/requirements.txt
📚 Learning: pytorch 2.6.0 wheels with cuda 12.4 support (torch-2.6.0+cu124) are available on the official pytorc...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1463
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:15-15
Timestamp: 2025-07-22T14:31:20.315Z
Learning: PyTorch 2.6.0 wheels with CUDA 12.4 support (torch-2.6.0+cu124) are available on the official PyTorch CUDA index at https://download.pytorch.org/whl/cu124/ for Python versions 3.9, 3.10, 3.11, 3.12, and 3.13 on both Linux x86_64 and Windows AMD64 platforms.
Applied to files:
jupyter/tensorflow/ubi9-python-3.12/requirements.txt
📚 Learning: in the opendatahub-io/notebooks repository, the dependency pinning strategy follows a deliberate pat...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/datascience/ubi9-python-3.11/Pipfile:34-36
Timestamp: 2025-06-28T14:13:27.890Z
Learning: In the opendatahub-io/notebooks repository, the dependency pinning strategy follows a deliberate pattern: core `jupyterlab` package uses exact pinning (==) across all notebook images to ensure UI consistency, while JupyterLab extensions and all server components (jupyter-server, jupyter-server-proxy, jupyter-server-terminals) use compatible release (~=) pinning to allow automatic security updates and bug fixes while maintaining API compatibility.
Applied to files:
jupyter/tensorflow/ubi9-python-3.12/requirements.txt
📚 Learning: the jupyter-bokeh pinning to 3.0.5 in trustyai notebook image was not due to trustyai code compatibi...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1218
File: jupyter/trustyai/ubi9-python-3.11/Pipfile:49-49
Timestamp: 2025-06-28T14:21:09.429Z
Learning: The jupyter-bokeh pinning to 3.0.5 in TrustyAI notebook image was not due to TrustyAI code compatibility issues, but because the trustyai package itself explicitly declares jupyter-bokeh~=3.0.5 as a hard dependency, causing pip dependency resolution conflicts when trying to upgrade to jupyter-bokeh 4.x.
Applied to files:
jupyter/tensorflow/ubi9-python-3.12/requirements.txt
📚 Learning: odh-elyra uses universal wheels (py3-none-any) rather than platform-specific wheels, making it compa...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1325
File: jupyter/datascience/ubi9-python-3.11/Pipfile:32-32
Timestamp: 2025-07-07T14:54:57.907Z
Learning: odh-elyra uses universal wheels (py3-none-any) rather than platform-specific wheels, making it compatible with all supported Python versions through a single wheel file.
Applied to files:
jupyter/tensorflow/ubi9-python-3.12/requirements.txt
📚 Learning: in the opendatahub-io/notebooks repository, the test runner's python version (configured in github a...
Learnt from: jiridanek
PR: opendatahub-io/notebooks#1247
File: .github/workflows/build-notebooks-TEMPLATE.yaml:50-53
Timestamp: 2025-07-01T14:36:52.852Z
Learning: In the opendatahub-io/notebooks repository, the test runner's Python version (configured in GitHub Actions UV setup) intentionally doesn't need to match the Python version of the container images being tested. jiridanek's team uses Python 3.12 for running tests while images may use different Python versions (like 3.11), and this approach works fine since the test code is separate from the application code running inside the containers.
Applied to files:
jupyter/tensorflow/ubi9-python-3.12/requirements.txt
🔇 Additional comments (9)
runtimes/tensorflow/ubi9-python-3.12/requirements.txt (3)
112-138: argon2-cffi-bindings bump is fineVersion bump to 25.1.0 is consistent with
argon2-cffi(Line 109) and upstream release notes show no breaking API changes.
1015-1070: matplotlib upgrade LGTMBumping to 3.10.5 is a straightforward patch+minor update; no API removals between .3 and .5.
1876-1884: py-spy upgrade LGTM0.4.1 only fixes symbol resolution on aarch64; safe for runtime images.
runtimes/datascience/ubi9-python-3.12/requirements.txt (1)
955-1010: Matplotlib 3.10.5 has cp312 wheels for both x86_64 and aarch64—safe to upgradeVerified via PyPI JSON:
- manylinux2014_x86_64 wheel
- manylinux_2_27_aarch64 wheel
No ARM64 source builds or extra dependencies will be pulled in; no further action required.
jupyter/tensorflow/ubi9-python-3.12/requirements.txt (5)
1244-1299: Matplotlib patch bump LGTM3.10.5 is a pure bug-fix release; no known breaking changes for our stack.
1672-1674: odh-elyra 4.2.3 bump acknowledgedUniverse wheel, no ABI impact – good to go.
2158-2166: py-spy patch bump – ensure binary wheels land in minimal runtime images
py-spyships manylinux static wheels; just ensure the slim runtime images that excludepatchelfstill work. Otherwise fine.
2322-2324: PyGitHub minor bump introduces async helpers – double-check any monkey-patchingThe public surface is stable but a few deprecated aliases were removed. Search the codebase for direct attribute access (
_requester,_Github__...) and adjust if necessary.
118-144: argon2-cffi-bindings 25.1.0 wheels verified for x86_64 & aarch64—bump is safeI ran the wheel-presence check and found both manylinux and musllinux wheels for Python 3.9+ on x86_64 and aarch64:
• cp39-abi3-manylinux_2_26_{x86_64,aarch64}.manylinux_2_28_{x86_64,aarch64}.whl
• cp39-abi3-musllinux_1_2_{x86_64,aarch64}.whl
• (Plus cp314 build artifacts, though the abi3 wheels cover Python 3.12)No source build is required on either architecture—CI will remain green.
jiridanek
commented
Aug 1, 2025
There was a problem hiding this comment.
/kfbuild odh-workbench-jupyter-minimal-cuda-py312-ubi9-on-pull-request
|
@jiridanek: The following tests failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
How Has This Been Tested?
Merge criteria:
Summary by CodeRabbit